Anatomy of a side project

I’m a huge fan of side projects. They give me a chance to try things I could never get paid for, like brand design. They also provide an opportunity to explore new technologies, languages and approaches that wouldn’t make sense to use at work. I end up having more ideas for side projects than time to do them, so I try to follow these rules of thumb:

1. Have a clear goal

So many times I’ve started a side project by coding for hours on features I end up dropping instead of spending a few minutes clarifying my goal for the project. Your goal could be to:

Learn a new language or framework
Build a quick tool
Make a sellable product
Create a community resource

There is no right or wrong goal, but it must be clearly defined. If learning is your goal, you can choose to skip adding the polish necessary to make a valuable community resource. Your goals also inform downstream decisions, like programming language, framework, and deployment. A clear goal makes other tradeoffs easier to evaluate. One additional heuristic I've found helpful from Simon Willison is: if you have a login screen, you’re a product, not a side project.

2. Put in more and less work than you think you should

This sounds contradictory but hang with me. You should put in less work than you think, only doing enough to complete the project. This isn't your full time job and you have other responsibilities, so you can't take forever. But on the other hand, you should put in more work than you think you should because you want to be a good assistant to your future self. Your future self will (probably) need to update dependencies, re-release or fix bugs in this project. If you want future you to be able to easily jump back in, you're going to need to have good documentation, pain-free deployment, and tests or code-verification processes.

There are two types of work, one-time and ongoing. You want to minimize ongoing work, at the cost of a bit more one-time work. In one of my more recent projects, I spent a non-trivial amount of time automating the build and release process using Github Actions. As I hit roadblocks while trying to get it working, I wondered if the effort was worth it. Once I was done and pressing a button created a release, I felt relieved and empowered in future development, knowing I wouldn’t have to worry about building and releasing ever again.

3. Remember that not building anything can be a win

One of my favorite articles about side projects is about Robin Sloan's family social chat app. He compared the project to a home cooked meal and I realized what an apt analogy a meal is for side projects. Just like not all meals you eat are home cooked (and there are times it is better to order take out), not all ideas should become your side project. There's no shame in ordering takeout! If you can find a good alternative that meets your need, drop a few dollars to purchase it or leave a tip.

Not too long after my son was born, my wife started tracking all of her meals to make sure nothing she was eating was affecting him. She mentioned how nice it would be to take a picture and have a way to automatically track which foods were in the photo. My creative juices started flowing and I began brainstorming how I would build a solution. After a few minutes I realized that there’s already an app for that and it was better for me to spend $20 and buy it rather than spend 20 hours trying to build it. Another upside to not building one project is it frees up time for future projects.

4. Prefer simple interfaces and low maintenance technologies

Unless you plan on only having one or two projects, you should focus on long-lived technologies that require little to no maintenance. For example, a iOS or Android app takes much more ongoing work than a web app. Simple, stable interfaces, such as email, are often the best choice and the constraints push your creativity while keeping the project easy to maintain. Another dimension of maintenance is deployment and release. I'm a huge fan of serverless functions for side projects, since you can usually keep costs low and you don't have to worry about keeping a server up and running.

One of my favorite examples is a side project I built called Coach Swole. It's a simple email-based weight tracking app I built for me and my wife. Every morning it sends an email asking for a weight in. You respond with your weight from that day, it stores that in a database, and it sends you a follow-up email with your rolling average, a fun meme and a chart of your weight over time. There's no sign up flow, it runs in a serverless function on Cloudflare and uses email as the user interface. It has required almost no maintenance and is easy to add features to - a perfect combination for a side project!

5. Have fun

Almost nothing is 100% fun but only keep a project going if overall it brings you joy. Unless it’s something you need to achieve other goals, such as career advancement, do things that are exciting and energizing. Side projects are valuable for me because they allow me to pursue programming for the joy of it, not just because it's something that needs to be done. It also reminds me of why I started programming in the first place and why I still love this career.