The Case for Developing Personal Projects Like Your Day Job

Published on May 28, 2025

Lately I’ve been trying to build my personal projects like I would for a day job.

What I mean by this is:

• Descriptive commit messages, using NumPy’s conventions
• Making PRs for new work, allowing me to organize changes that may take a while or I don’t want to finish right now into their own long-running branches
• Documentation
• Automated formatting and test suites (this one is still a WIP)

This does add some extra work; mostly at the start, but in general it adds a little more work for each change, even if those extra steps take only a couple of seconds each. For a personal project, it’s arguable that you might just want to see results, so adding the sort of ceremony and guardrails that a “serious” project that contributes to your employer’s bottom line has, isn’t worth it. I think that this is a reasonable position to take, and it’s generally how I’ve worked on my hobby programs in the past.

But I think that there is also an argument to the contrary: for a hobby or passion project, you don’t have any deadlines. Maintaining a clean project definition file, a fully-featured Makefile, and documentation all help you move faster and pick your project back up after life diverts your attention from it. It allows you to reflect on your approach to “heavier” projects in a lower stakes and lower stress environment. On the intangible, emotional side, doing things this way can instill a sense of pride in yourself and your output. You’re a craftsperson and are putting a lot of thought and effort into everything you put out into the world.

If you take this approach, it is important to not let the perfect be the enemy of the good. I have a To-Do’s page on this blog that lists changes I want to make. That page is incomplete and will always be growing since there are always more things I can think of when it comes to improving my features, process, or presentation.