I’m a Software Polygamist
I’ve spent the last 18 months working under the radar on a new app with fellow Mac developer and long time friend Alexander Griekspoor. Agenda is a new take on note taking, with a focus on projects evolving over time.
Alex and I have similar backgrounds, each starting out in science, and leaving to chase the indie dream, developing apps for the Mac, and — later — the iPhone and iPad. As the original developer of the app Papers, which went on to win an Apple Design Award and become a commercial success, Alex knows what it’s like to start very small, and build up to something more significant.
It’s been quite a marathon for both of us, and we still have a long way to go, with the final release of Agenda for macOS imminent, and then the development of iOS apps.
It’s not the first time I’ve worked like this. As a solo indie, you often have long stints of a year or more working on a major upgrade or new product. It takes a certain type of discipline to keep plugging away on something that won’t see the light for quite some time, keeping up your motivation, and pushing through the doubts that arise on every single decision. It’s certainly not for everyone.
But when it comes to working incognito on seemingly endless projects, I have a confession to make — I am not always faithful. Sometimes I cheat. I moonlight on other stuff. I need to. I need the mental stimulation; to break out of the rut of an ongoing, constraining project. When it comes to software, I can’t be monogamous.
Since I began on Agenda, in addition to maintaining my other projects (Studies and Ensembles), I’ve dabbled in a decentralized Swift value store and a genetic programming framework.
These projects often come out of activity in my day job that I want to investigate unhindered. For example, Agenda is written in Swift, and uses value types extensively in the model. When you are developing a major project, you sometimes just have to get it working as best you can, in the time you have. I could see there were a few deficiencies in how we had implemented some solutions in Agenda.
The academic in me then wants to know more. What if you took this approach to the natural limit? What if you did it all “right”, the way it should be done, with no constraints or limitations? What if you made it as pure as you could make it?
These ventures don’t eat into my day job. I tackle them after hours “for fun”, chipping away an hour a day when I can find it.
You might ask “But what if you used that time on the main project? You could get more done.” Maybe, but I can’t do that. I have a clear separation. There is that marathon I am running each day, and then there is recreation. I need that recreation, and just doing more of the day job would drive me crazy.
Besides, my little “flings” are never wasted. My goal in these projects is always to do it “the right way”. If there is some aspect I don’t fully understand, rather than find a workaround like I might need to do in my day job, I learn how to solve the problem properly. In my side project, I learn skills, and come to realizations, that later become very useful.
This has already happened a few times on Agenda. We start to see an issue in the design that is causing issues. How do we solve it? How can we improve the design? Having thought through the issues in a side project, it is immediately clear to me what we have neglected, and what the various options are.
If you ask me, every software developer should cheat a little on their day job. Flirt with other programming languages; develop whole apps or frameworks on the side; perhaps get involved with open source. It breaks the monotony, but — more importantly — it keeps you sharp, and nearly always pays back at a later date — it’s never wasted.
