A commit a day keeps the boredom away
Most hobby projects die at the idea stage - Mine do not. A while ago I decided to revive an old idea of mine to implement the International System of Units as a strongly typed C++ library. In order to try to bring this project forward I tried an experiment: I would make at least one commit each workday for a month. A month later I am somewhat proud to say, that I kept this promise to myself with only one “comittless” day. But how does my pet project look now?
I’m I done yet?
On average I spent around 30 minutes a day on my project, mostly during my lunch break, sometimes when riding the train to or from work. It is not surprising that when looking purely at the code my library made some progress, but is still very far from being useable in production. In fact a lot of the intendend functionality is still missing. I haven’t even gotten around to implement all the base units yet. On the other hand a lot of very cool functionality such as compile-time unit tests and mathematical operators are already in place. I’m also quite proud that I have a working CI system and that I was able to pull off Test driven development. And of course I learned a lot of things and experimented with some concepts of modern C++ in ther process - After all the goal of the idea was not just working software but also to learn a lot.
However more interesting than the actual output measured by code is that spending a small amount of time each day put me into a state of creative flow. When I started my “month of commitment” the project was in the state of a pure experiment: A few badly formatted, hacked together files that already proved the concept of what I wanted to do, but the code was very far from a state that I wanted the world to see. So I threw them away, created a repo on github and started to get to work from a clean slate. Step by step the project grew in the familiar pattern of TDD: write a test, make test run through, refactor. Each test and feature completed led to the next in a quite natural way. And when I struggled with something there was always some documentation to add or some class to refactor.
When I started was very much worried, that my limited time each day would be a problem, but surprisingly that was not the case. By doing TDD I was able to formulate the project into a string of small problems to solve, most of them not taking more than half an hour by itself. It was usually the refactoring afterward that demanded bigger timeslots, but being aware of that allowed me to schedule my activity a bit. The interesting lesson here is that by being able to fracture the project into a string of small problems and having a high confidence of not breaking anything while refactoring I made a lot of progress with comparatively little time invested.
Getting into the flow
Even more interesting than actually being able to further the project in small steps was that it did not take long and I started to feel a flow of creativity. When I was working on one feature the next problem started to form itself in my brain and I could effortlessly create and maintain a small backlog for myself. The orignial idea of building a strongly typed library for physical units remained always in my mind. But soon I added the idea that it could be almost entirely compile-time validated under the right circumstances, which led me to rewrite the necessary tests also to work on compile time. Compile time verification is of course dependent on the compiler, so I needed a system for continous integration which let me allow multiple compilers - enter Travis CI. Then came my internal dispute about using static_asserts or std::enable_if and SFINAE to ensure correct usage of the library and so on and so forth. These ideas sprouted up naturally while already doing it, a wonderful feeling.
This train of though went on and on - in fact it is still going on. One thing led to another with minimal conscious effort on thinking what do do next. And if I needed a bit more time to think, then I would do some trivial task like documenting, fixing naming inconsitencies and so on. I came to recognize that having this state of flow and clear goal to pursue is very valuable and rewarding when one tries to get things done. On one hand it kept the project interesting to complete because I constantly had to think about new things ond the other hand I frequently got the satisfaction of getging something done by splitting it into smaller problems.
Being able to push my pet project with so little effort made me realize what we often throw away in our professional environments. Developers have no clear goal or alignment towards it severly limits their ability to come up with new ideas on how to improve what is already there. On a more hands on side it is apparent that TDD not just helps with code quality but also can be a tool to split functionality into small, workable problems. Combined with constant refactoring that makes a code-base “feel” really good to work with this can make for a very efficient way of extending and improving a code base, as is evident in how much I could achieve by just spending half an hour each day in such an environment. And getting things done combined with the joy of mastering a craft is a very strong motivator.
And now?
The journey towards a library that supports the International System of Units is still going on. I might get a bit more lax with the one commit a day rule, I fully intend to keep a steady cadence of commits up for the time being. Let’s see how much in the flow I am in a month or two.