Leaning on The Pomodoro Lately

It's funny how accidentally we discover things sometimes... a lot of the time. I think it would be interesting to have a catalog of things I've discovered on purpose, and things that I've discovered by total accident. I suppose that's simultaneously one of the best things about the very nature of the web (accidental discovery) and one of the the worst things (my quest for "accidental discovery" can be a complete timesink). 

I remember sitting in my cubical at my first programming job at TRX in Atlanta, GA, scouring the web for an answer to something (probably how to formulate some regex to scrape data off of a passenger name record), when I stumbled on an article about something called the Pomodoro Technique of all things. I remember reading the article and thinking to myself, "What a novel idea... sounds interesting... I think I'll give it a try sometime." In it's most basic form the Pomodoro Technique is a method for managing your time developed by Francesco Cirillo (when he was a college student) where you:

1. Pick something that must be done.
2. Set a timer for 25 minutes.
3. Work on the task.
4. End work when the timer rings.
5. Take a 5 minute break.
6. Repeat 2-5 until your task is complete.

I think at the time, I toyed around with working on a few things using Pomodoros... but the technique didn't immediatly stick for me. I don't think I was serious enough about it, even if I had seen some benefit out of using it for a few things. 

Flash forward several years... I'm at a new job with a great group of developers that I learned a lot from at VersionOne. They had a deeply-seated tradition of pair programming, which was new to me at the time. One of the things that we all loved to experience when pairing was a sense of getting through the things we needed to get done with a sense of flow in getting through them. To that end, a couple devs liked working via a Pomodoro Timer. 

Kept with us during the 25 minutes was a sheet of paper to record anything that was important to come back to and take care of, but not germane to the task we had at hand. These two practices I have kept with me and have used on and off ever since I learned them. Sometimes I have been more disciplined about the timer, and other times not as much. I have always... always... kept the habit of a small piece of paper to record things on to come back to. As humans, we're not built to keep track of more than about 4 things at any given time. The little piece of paper is the external brain that frees me to be more creative. More on that in another blog post.

Flash forward a few more years and here we all find ourselves wrapped up in the hands of a COVID-19 based pandemic, and for those of us fortunate enough... working from home full time. Many of us also found ourselves as poor substitutes for the amazing teachers that our kids had in school. Here we were, overnight seemingly, tossed into a world where we were expected to be as productive as we had ever been at work... and also be immediately available for our kids when they needed help for something related to school... or any other creative thing that came to their minds. 

Time management and retaining a sense of flow in my work life became an immediate challenge. My kids needed help understanding some of their assignments, and I was their substitute teacher. My employer required me to be continually making progress on all things work related. How was I going to get through this without making my kids feel guilty for asking for help? How was I going to claim the time required to make meaningful progress at work? Hellooooo to tha Pomodoro!!

I've rediscovered my disciplined relationship with the Pomodoro Technique. There were several days where at the end of the day I was asking myself why had I not completed anything. It was in part the nature of the work that I was working on, and in part needing to be the awesome dad/substitute teacher my kids needed me to be. I've been using the Pomodoro Technique as I always have, really no different other than I don't really pair at my current employer. I'm just using it much more regularly lately than I had been over the past year or so. It's helped me with letting my kids know when they can snag me to ask questions they have needed help with. And it's helped me with staying focused and on task to get through the day to day coding work that I do. The family get's me for little windows of time, and I get a state of flow through my day. It's honestly been a godsend.

All of that having been said, my hope is to start utilizing some of the aspects of the technique that I haven't been using. If I'm successful in pulling them in, I'll check back here and share how it has affected my work. If you've not ever tried the technique, I encourage you to give it a shot. I think you'll be surprised at how helpful and useful it can be.

Sometimes... you take a detour

To say it's been a while since I've touched my side project (Calm) would be a complete misrepresentation of how long it's actually been. As you can see from my last post back in... um.... 2018... it's been a little bit longer than "a while". But, that's cool, life happens and I'm back at it, and that feels good 😊.

Since I've started picking back up the pieces and hints that I left myself, I've been somewhat confused by the highly technical notes that I left behind. Current me is trying hard to remember the context of some of these notes that past me left!! Nonetheless, I'm making some progress. One string of the yarnball that I started to pull on was beginning to use an environment file for some of the application level configuration (a tenet of The Twelve-Factor App). If you're unaware of the principals behind what is described at The Twelve-Factor App, I encourage you to give their site a read. As for configuration for your app, they require a strict separation of the config from the code. Things like port numbers, database connection strings, and 3rd party api tokens.

That's all well and fine! I did hit a little bit of a snag with my unit tests gaining the appropriate load of my environment variables when running my tests through Wallaby.js though. I took a dependency on the 'dotenv-flow' npm package into my app.js file, and wrote a test that ensured it was being used and that the port I was expecting was also being used where I anticipated it should be.

Perhaps not the most useful of tests I know, but sometimes I push things to the dogmatic edge just to see if I can, and to experience what challenges there are in doing so. Lo and behold, an unexpected challenge presented itself. My port was continually getting reported as undefined, regardless of what I tried. When I ran the app on it's own via 'npm run start', the port was console.log'ed as expected. I was not as lucky from within my test suite though. I was having a hard time finding an answer, and my google foo... for whatever reason... was failing me.

That was until I stumbled on this issue in the Wallaby.js repo. The Wallaby configuration file needed to load the .env file in order to make it's contents available to my testing context apparently... like this:

'use strict';
require('dotenv-flow').config();

module.exports = function () {
    return {
        name: 'Calm',

        files: [
            {pattern: 'src/**/*.js'},
            {pattern: 'app.js'},
            //list helpers for tests last, per wallaby's suggestion
            {pattern: 'testHelpers/*.js', instrument: false}
        ],

        tests: [
            {pattern: 'test/**/*-spec.js'}
        ],

        env: {
            type: 'node',
            runner: 'node'
        },

        testFramework: 'mocha',

        setup: function() {
            chai.should();
            var sinonChai = require('sinon-chai');
            chai.use(sinonChai);
            global.sinon = require('sinon');
            global.next = function() {};
        },

        lowCoverageThreshold: 99
    };
};

Now, does my use of a .env file completely satisfy the advice given the the author(s) of The Twelve-Factor App philosophy? No, I don't believe it does. However, it is a good first step that is better than having these types of things hard coded into the application itself. I suppose the next extension of their advice would be to have CI set the environment variables on the server itself that the code is deployed to. I'll tackle that one on some other dogmatic day, lol. Did my dogmatic requirement for this project having at least 99% code coverage force me to learn something new today? It did, and that's worth the effort to me.

Using 'host' while Bootstrapping Calm

I've been in the process of bootstrapping Calm (a new app I'm building out as part of my side hustle). Every time I set up a new project from scratch, I'm reminded of those things that I do only very rarely. Setting up the VM, nginx, ssh, firewalls... all of these are things I do rarely in comparison to the day to day development work that I do.

I'm always pleased to find a new small utility or tool along the way. Today I found the host command for verifying that the dns servers that I'm hitting from my house have the updated name servers I just adjusted with my domain registrar. It's an alternative to nslookup, and gives some really useful information.

For my needs, the following did the trick

host -t NS getcalm.io

The -t NS piece tells host to query for name servers, which was just the piece I needed. And yes, I was pleased to find that the new name servers had already propagated.

getcalm.io name server ns3.digitalocean.com.
getcalm.io name server ns1.digitalocean.com.
getcalm.io name server ns2.digitalocean.com.

Monday Night Rituals

Monday nights for me have a ritual on them now. I say now, but in reality they have had a ritual on them for several years now. Several years seems about the right amount of time to actually claim something as a ritual I suppose. It's for sure past the 66 days it takes to formulate a new behavior.

Anyways, the ritual is I meet up online at 10PM Eastern / 7PM Pacific time with a good friend of mine, Dan Gilkerson, and discuss "stuff". Mostly we chat about side projects we are working on, but it can range widely depending on what we've been involving ourselves with and who else is on the call. How do I lay out what this "stuff" is. A list would probably work best.

1. Helpful patterns to use in meteor.js.
2. What's a good name for our latest project idea (namecheckr is a fantastic tool to check name availability for this).
3. Here's an idea similar to one we've had, and look someone has built a project around it.
4. What's the latest thing Dan has learned in his latest hobby.
5. What Kickstarter has peaked our interest lately.
6. What's the next thing for XYZ side project we are tackling.
7. ... A plethora of other things 

The Monday night meeting started out of a desire to make getting together and working on extra projects routine. Not only routine for us, but also routine for those around us. Being a married father of two, it can be hard to fit things in that don't revolve around the family. A routine Monday night meeting has helped in that endeavor. It's not that I don't love my family with all of my heart and enjoy spending time with them, I do.

Meeting later in the evening for me has helped with fitting things together. By 10:00PM we've gone to whatever after school activities are up for the day (soccer/dance/t-ball/kungfu), we've eaten, completed all homework, hung out, taken baths, and gotten the little angles that are my children down for bed. It gives me a good hour to decompress after the kiddos go down to sleep. My rule is to try to be done with the meeting by 11:00PM or 11:30PM at the latest so that I can still get a relatively good nights sleep.

I bring this up to say this. That if there is a side project that you intend to do, outside and beyond what you do in your day job, start with one simple ritual. Our Monday Night ritual is one of a series of rituals that I've put in place to try to make it to that next lilypad in the pond of life for getting some successful side projects flowing. You may ask, are they successful? Is anyone using them? Yes, some are. Not huge successes yet, but enough success to be able to watch people use the systems, which gives us feedback for what's next.