John Resig of jQuery fame wrote a blog post back in 2014 titled “Write Code Everyday”. The post got mixed reactions, some loving his suggestions and others saying it was literally the worst thing ever, but the post always stuck with me. In the post, he talks about developer’s side projects and finding time to actually make progress on them. The common thinking and practice is to dedicate your weekends to these side projects, because realistically you won’t want to sit down for an hour or two coding after a long day and commute home. This is a problem though. For starters, as he points out, a week apart from being within a codebase means you spend more time trying to remember where you last were and getting things moving again. For me personally though, the biggest problem with dedicating two days to numerous projects puts this mental ticking clock in the corner of my mind. I have some mental idea of how much I want to get done, but as is common in development, bugs and problems will arise that put the brakes on this progress. That can make things much more frustrating than they actually need to be.

So John came up with the idea of coding everyday. Just like Daily UI, he challenged himself to write something each and everyday, and even gave himself guidelines for what was acceptable or not. Lately I decided to do something similar. My challenge to myself isn’t as strict as Resig’s, (his work had to be open source, it couldn’t just be docs or refactoring of code) but is in the same vein. Ultimately I have to push at least one commit to any of the side projects I have each day. It is an exercise in managing your time for sure. On some days when I know I’d be working late, I code a bit early in the morning or during my lunch. So far, my experience has been pretty similar to John’s I think. Namely in how I view “progress”.

I realized that the feeling of making progress is just as important as making actual progress.

That quote from his post nails the benefit I feel from working on my side projects each day, regardless of how small or large the commit is. I started to learn this while working on getting this blog up and running actually. I didn’t allow myself to get caught up on having some polished and perfect design, or make sure that every single feature I have in mind is present upon launch. I made pretty fast progress on it and was happy with it compared to past attempts where some small thing would annoy me and I’d never come back to just move forward on it. Solutions will show themselves, it’s just way too easy to let them reign over us at that moment.

CommitStrip.com - Commit or die trying Copyright CommitStrip.com

My attempts at making “one commit per day” a habit has helped with the feeling of “code burnout” that has been plaguing me for awhile now. I’ve found myself thinking of excuses to try new frameworks or libraries thanks to some random small idea that only myself or a handful of people will ever actually use. It’s probably not for everyone, but I’d suggest other developers struggling with moving forward on their personal projects give it try. Coding for myself has become fun again lately and has the added benefit of freeing up my weekends to go out with friends and not feel guilty for not getting something done.