It has been 14 days since I said I’d be committing for 30 weekdays straight. I’ve committed code 12 out of those 14 days. (This weekend Eliza and I painted our living room so you’ll have to forgive me for not pulling out my computer.)
What have I accomplished? What have I learned?
These last 14 days have been some of the most productive we’ve had on Unmark, Barley for WordPress, and Barley CMS in over 9 months. I’ve been setting aside time each day to make some progress on our internal products — whether or not there is client work to be done.
With Kyle’s help, I’ve been able to release several key updates to these products and become so much more familiar with their codebases than I was just a few weeks ago. You see, I didn’t write Unmark or Barley CMS. I wrote most of the code for Barley for WordPress, but the other two I was nearly starting from scratch in my knowledge of their codebases. Fortunately for me, Jeff and Tim both did a great job writing documentation to catch me up-to-speed.
Once you hit this rhythm, though, it is a really nice pace to work at. Each day I have a little time for products, a little time for client work. It breaks up the day in such a way that each day flies by and, even if I get stuck on a problem, I tend to have a fresh perspective on it within a few hours. My entire career I’ve found that backing away from a problem only to return to it later usually yields good results — this new schedule affords that to happen daily.
I’ve also found that, at this pace, I’m far less likely to put up with bottlenecks in my workflow. For far too long I’ve had several tasks that I had to do manually that, now, I’ve either automated or eliminated entirely. And I hope to continue to knock a few more of these tediums off the list as these next few weeks continue.
I’ll give you an example: the way we build the Barley Editor for use in multiple products; such as Barley CMS and Exposure, is somewhat tedious. It requires a bit of institutional knowledge and if one piece is wrong due to human (read: me) error then the whole thing breaks down. By the time I’m done with this next sprint I’d like to have this build process be much smarter or eliminate it altogether.
Another thing I’ve noticed is that I want my git history to be much cleaner. For some things I’ve needed to push commits to Github in order to properly deploy them to either our development or staging environments. This creates a million unnecessary commits. I’d prefer my git log to be a lot more clean and easier to work with and move around in. So I’ll be looking for ways to make our development and staging deployment routines a bit easier to manage. And my usage of git to be a bit more proper. This should help make git much more valuable longterm for our team.
Oh, and one last thing. I should have started this commitment to committing 9 months ago.