The Chaotic Debut of My Typical Software Project
I am no stranger to the exciting feeling of starting new projects. By dint of repeating this “exercise” over the years, I have come to build an intuitive process which works for me. In this write-up, I want to give a try at describing it, both for future references and in the hope that this might start interesting conversations. I am curious to know whether or not my personal “process” is shared with some of my fellow developers, though I would be surprised if it weren’t the case, since there is nothing particularly clever or revolutionary with what I am about to write.
In a nutshell, I can often divide the early days of my software projects into two phases: the exploration phase and the rationalization phase.
The starting point of the exploration phase is a need, and a direction I want to take to address this need. For instance, the starting point of the Compact module of data-encoding was the need to encode in bytes arbitrary values, and the direction was to do that with data-encoding. For Spatial Shell , I wanted badly to enjoy Material Shell ’s user experience without having to switch to Gnome 3 and the direction was set when I discovered sway’s RPC protocol .
The goal of the exploration phase is for me to turn the direction into a destination, so to speak. When I start, my knowledge of both the problem I want to solve and the solution I am trying to build is vague, and needs refinement. There are intuitions I need to challenge, APIs I need to learn, boilerplate I need to understand. More often than not, this phase is messy. Commits are not nice, standalone units of changes: it is way too early for that. I use Git merely as a way to throw away a dead-end, and resume exploring down another path from a reasonable save point. I put most if not all my code into one file, I don’t write comments, encapsulation and abstraction become foreign words I forget about for a while. My goal is to come up with a prototype which captures the key features I am looking for, and to learn as much as possible in the process. This exploration phase shouldn’t last too long, because it is very context sensitive. If I am interrupted long enough, I am likely to lose the mental map of my messy code, and to forget the key insights I was learning while navigating it.
