There are often two problems a developer faces when working on side projects. The first is being too precious about their work. Everything needs to be done “right,” and thus they usually make very little progress with the limited free time they have. Secondly, more often than not, developers have too many ideas they want to work on. The combination of these two things leads to a GitHub page filled with half-completed projects. I can confidently say that most developers have gone through their GitHub page and deleted a bunch of repositories that had no actual meaning or purpose other than being a reminder of an idea they once had.

Doing things “right” is a broad term that can manifest in many ways. Maybe you're following TDD and trying to achieve 100% test coverage, using all the hottest new JS frameworks, spending days tweaking styles, or writing your app in the fanciest of FP languages. There is only so much free time in a day, and if the primary goal of the project is to do it the “right” way, that’s totally valid, but this will greatly decrease the speed of your output.

Developers, by nature, find problems in their environment and try to solve them. This tends to lead to a laundry list of project ideas written down in a notebook or saved on a phone, becoming analysis paralysis about which project you should be working on. If you choose the wrong project, a slow frequency of output could lead to apathy towards your side project, which in turn leads to abandonment.

At this point, I want to be clear. There is nothing wrong with doing things the “right” way or having a laundry list of ideas. It’s all about the management of these two competing sides of your brain. As someone who has for many years suffered from these problems, I’ve come to a simple realization: ship your hobby code often.

What do I mean by that?

Break down ideas into increments of small MVPs or vertical slices. Maybe you’re trying to learn a new language and want more than just a todo list to work on. Find something quick you can make a simple clone of, like Twitter, HackerNews, or YouTube. If the project is a more fleshed-out idea and less about learning new tech, find shippable features that would bring value on their own. This allows you to figure out not only what technologies you enjoy/are productive working with but also which ideas really spark your creativity.

Take this website, for example. At the time of writing this blog post, in April 2020, I’m writing this in a JSON blob because Markdown support isn’t implemented, I don’t have a backend CMS, and the idea of learning Gatsby added a big question mark to what I could actually get done. I know I will eventually get to these things; however, neglecting them has allowed me to ship a fully functional website in a week. This frees me up to either continue improvements to this site next week or build out an MVP for my next idea.

Shipping your hobby code often is a rewarding feeling. It scratches that instant gratification part of my primate brain in the same way completing a series on Netflix over the course of a weekend does. It has brought back the joy and motivation of hobby programming I’ve felt like I’ve lost in recent years.

Author's Note:

This was written at the beginning of the pandemic when I was living alone, struggling with everything happening in the world, and trying to keep myself busy with programming. I wanted to leave this post as it was originally written for posterity. However, if I were to rewrite the message, I would want to convey more clearly that it's better to ship code than to let it lie dormant in a GitHub repository. Just like in work, smaller, shippable features are preferable to never-ending, self-inflicted scope creep.