Coding every day

I recently read write code every day by John Resig. I’ve been trying to follow a similar set of ideas for a while now. My rules were less restrictive than John’s were. My rules were:

1. I must do something everyday. Writing documentation, opening new issues, writing code or reviewing and merging other people’s code all count.
2. The code has to be published in a public place.

Like, John’s rules, mine are pretty arbitrary. I had a few goals. I wanted to:

1. Maintain and hopefully increase the momentum I had in my side projects.
2. See if I could get into a daily rhythm that would be sustainable long term.

Since July 2013, I’ve been trying to follow these two rules. Since then, I’ve managed to keep a 270+ day streak running on Github.

I feel that I was able to achieve the two goals I had set out to accomplish. I’ve learned a few practical things in these 270+ days that I think can be helpful for others with similar goals:

It has to be a routine Much like brushing my teeth, or eating. I’ve found that having a specific time of day when I do my side-project work has been helpful. For me it often falls ~8:30-10:00pm after my kids go to bed. Having a consistent time means I can schedule it with my other home responsibilities. On days when I have plans in the evening, I try and choose tasks that I can fit into my lunch break, or before I go to work.

Have multiple side projects While I try to focus on CakePHP in my spare time, having side projects like xhgui and Lint-Review have helped provide a change of pace when I needed a break, but didn’t want to break my habit.

Break big tasks up Much like an ‘agile’ process, I can only get so much work done each day. Forcing myself to keep a daily beat, has helped me improve my ability to break big blocks of work up into smaller tasks that I can do in evening sized portions. Breaking big tasks up has a few side benefits as well. Small blocks of work are easier for other people to understand and review.

Split documentation and code up From my experience writing code and its documentation in tandem is really helpful for ensuring features get built whole. However, breaking the code and documentation up into separate evenings lets me get two days of activity from one task.

Overall, I’m pretty happy with the results I’ve had. I feel like I’m making great progress, which is evidenced by the progress on CakePHP 3.0. I also think the experience in breaking big tasks up has been valuable for my day job as well.