Ode to the Hobby Project — Matthijs van Henten

So this is going to be a bit of a rant and a bit of an ode to the hobby project. I think it's fair to say that hobby projects have been instrumental in my professional development as a software engineer and without them, I would not have made it to the position where I am: leading and architecting complex software together with awesome people.

I've spent a lot of time, evenings on various projects, scratching an itch that no-one else would care about. And those projects taught me a ton of stuff. Building something as stupid as a CMS forced me to learn the principles of good API design, understand proper data modeling and denormalized database design. Even at the time where my wife was asking me why I was spending so much time in something that she could just take off the shelf like WordPress, and finish that stupid website, my answer was because it doesn't feel right, because it needs to work better, more intuitively, more efficiently.

It always takes a bit of hubris to become a good software engineer. If you don't believe you can make it better, then you shouldn't even try. That hubris also taught me the value of unit testing, because any hobby project, as a golden rule to myself, should be something I can abandon at any given point in time and pick up at any given point in time again. With the code of a late night coding session, waiting for my one year old to get his last bottle at 2am, often the next day I would simply type git clean because none of it made any sense. By building unit tests suites and learning how to do proper test driven development, I started to make incremental progress and learned how to achieve my goals, one night at a time. Building up a project months apart, sometimes years apart.

So I learned the discipline and the principles of good software engineering, unit testing, documenting my work, creating projects that could self bootstrap with a simple script and a few instructions, industrializing my setup and creating a common architecture or layout for projects so that I could easily recognize where things were. Of course using version control, from CVS to SVN to the total alien GIT, just so that I could be forgetful, lose context at every given point in time and pick it up later again.

I've never had formal education in programming, and I studied arts instead of computer science, so I arrived late in the game, and I had to bootstrap basic skills well into my 30s, but that hard work did allow me to join a startup (Cloud9, c9.io) with a lot of crazy smart engineers owning PhDs in the field that I looked up to and that I could learn from, and to my surprise even bring a few new ideas too. And that startup was lucky enough to be acquired by Big Tech (AWS) and so I spent a few years inside at the height of their engineering culture, learning even more rigorous thinking and speaking, understanding how to bring data into the conversation and how to win an argument based on the right data points.

I also learned that the hobby project way is not for everyone. I've seen great examples, people who turned their passion project into an innovation machine, a problem solver, a dojo where they could run the katas of their software developer skillset. But I also worked with engineers who were so obsessed with their personal projects that they showed up late for work, worn out, tired and behaving egocentric. You see, the passion project is a place where you get to make the rules and you don't need to listen to other people. And if you don't like what you did yesterday, you can throw it away and start again. When working with real people in real engineering projects, in real companies, you have to suck up 90% of the suck, most of the time.

So here's my closing argument. I think that anyone that's currently plateauing in their career should pick up a passion project. Now is the golden age. The tokens are abundant, subscriptions are cheap. Buy the tokens, buy the hardware and be ambitious. Become the architect, the UX designer, the project manager.

Become rigorous in your approach. Become disciplined in enforcing test coverage and quality. Understand the trade-offs that anyone that isn't you but one level above you would have to make with regards to architecture, cost and complexity. Because where things are heading today, we all need to become multidisciplinary software engineers, not software developers with their heads in the code. We need to become creative and independent thinkers who can go from high to low complexity in seconds and be in the prompt if they need to.

We need to tinker, more than ever, to evolve the field of software engineering.

My graveyard of hobby projects is extensive - and not all reflecting my current day skill set or way of thinking but they're still out there. Funny enough the one that stuck is ellipsize: under a hundred lines, written in 2014, still about 710,000 downloads a month. I guess that was just good name squatting.

The rest of the trail, oldest first — 89 public repos since January 2011, I still own my abandoned projects:

pylatscan (2011) - a laser triangulation 3D scanner in Python
munge (2013) - an RSS feed reader written in Perl
string-entropy (2014) - estimate password strength (my first deep dive into information theory)
drawio-headless (2026) - render drawio diagrams in Rust, no browser, no Electron. Pure frustration.
mobux (2026) - a touch-friendly tmux web UI - My first project built exclusively on a phone during dog walks.