Nearly 2 years ago now I read a fantastic article by John Resig titled “Write Code Every Day” in which he describes a scenario where he’s not happy with the progress he is making on his side projects. To remedy this he decided to write code every single day and open source it. I can’t recommend reading through his original article enough.
I can admit I've not managed this, not even close, but what I have done is attempted it several times with slight adjustments, thought about it a lot and more importantly managed to get a whole lot more done than I had before.
This is what I've learnt about it
Don’t make it too strict
John’s article sets a lot of strict rules, such as all code must be open source, no refactoring etc. I’d love to open source everything I write but I'm way too self conscious and end up obsessing and worrying about silliest things (my love/hate relationship with Github has long been on my list of topics to write about so I’ll save this for a future post) and it made me not do it.
Every day is easier than other denominations
I found that writing code every day is the only time interval that works. Every other day sucks because a week has an uneven number of days and you end up rotating your schedule which makes it a nuisance to track.
Taking longer breaks between the sessions means you spend a lot of time reminding yourself where you got to, what you were working on and in general getting going again.
Short sessions work best
Short sessions are easy to slot in to your day, whether that’s first thing, during lunch or late in the evening. When I tried less frequent longer sessions at weekends for instance any other plans that came up would easily cost me the entire weeks allocation of time.
Half an hour is perfect
Half an hour is short enough period of time that if I'm not having a great day and I'm not in the mood I can suck it up and just do my time. That sounds worse than it is, 9/10 times I feel much better having done it. Like going running, you don’t always want to go out but you’ll feel good for having done it.
I quite often hear how half an hour is not long enough to do anything and most often it’s accompanied by how 3.5 hours a week which is less than a half days work is not enough time to make any realistic progress on a project. I've found this not to be the case and find that the half an hour can be extremely productive.
The back of the envelope maths which assumes you are productive for full 7–8 hours per day at work is simply flawed in my experience and highly motivated half an hour can be more productive.
Staying in the right mindset
Showering, commuting, exercising etc. all turn into prep time, I find myself constantly thinking about what I did yesterday and what I’ll be doing today. This means when it comes to my half an hour, I'm already in the mindset, I've already mulled all the ideas over and just ready to get on with it. It’s like finding extra time in a day!
Visual tracking works
Jerry Seinfeld is famous for his “Don’t break the chain” productivity method. If you’re not familiar with it he used to print a calendar for his wall and mark every day he did some writing with a big red X. The idea is that within couple of days you can see an unbroken chain and you don’t want to break it. The longer the chain gets the less you want to see it break.
Starting is hardest
I really enjoy writing code but like many of the other things I enjoy, I find starting them really difficult, I enjoy them once I've started but that first step is difficult. Once I would get started I wouldn't want to lose the momentum so I would stay up all night working on something as I wasn't sure when I’d be able to pick it up again.
Committing to every day has made it easier to start and it’s easier for me to stop as well as I know I’ll pick it up again tomorrow so it’s less likely to end up as yet another project I've started, worked on for a night and never got round to again.
Code doesn't have to be code
Most often my half an hour a day is writing code, today it’s writing this article, sometimes it’s contributing to open source, sometimes code, sometimes documentation. Sometimes it’s just taking half an hour to read through docs for a new language or framework.
With another year just around the corner I hope you've been inspired by either John’s original article or mine to give this a go in the new year. It doesn't have to be stressful and I can promise you’ll be surprised by how much you get out of it in a short period of time.
Recently I've spent my half hours creating and launching a tool to help others form a habit of this and to keep track of what they've done. I've called it CodeHalf and I’d love to hear your thoughts on it.