It’s late at night. Everyone else has gone to bed, but you’re up just a bit later. Your fingers are flying across the keys, your brain fighting against exhaustion but flowing with great ideas. In front of you, your laptop’s fans hum gently as your side project’s local environment runs in the terminal. Constantly switching between your IDE and the browser, you watch as your ideas come to life before you. It’s truly a magical moment. Just one more feature, and it’ll be ready to ship…
A week or two later, your app is still half finished, but the drive you felt that night has faded. New ideas have started to form in your mind, unrelated to what you were working on previously. You spun up a new Git repo, and you’re almost ready to buy a new domain name. It’ll fit nicely next to dozen or so others you’ve already purchased. One day, you’ll ship all of them. At least, that’s the plan.
Side projects get a lot of attention from developers. It’s common to visit someone’s website or Github page and find multiple projects on display, all in various stages of completion or function. On Twitter, I regularly see developers talking about their side projects, often lamenting the fact that they have so many and feeling guilting that they aren’t being released or finished. It’s especially common to joke about the number of domains that we all have purchased but never used. At some point, I think we as developers get depressed and frustrated because of all the things we started with the best of intentions, but haven’t completed.
Rather than stress ourselves out about the amount of work waiting for us when we get off work, I think it’s useful to put side projects into context: what they are, what they are for, and who benefits from them.
The Purpose of Side Projects
There are lots of reasons for starting a new side project. A new framework could have been released that has some new ideas, or you want to try a new language or library. You could be trying out some new techniques, or just want to explore an idea or two that you created. Before you start a side project, it’s important to understand why you’re doing it. What do you want to get out of doing this project?
When I was starting to learn React, I needed a project that I felt was interesting. Rather than build a todo list or something else, I came up with a basic turn-based strategy game. It was a lot of fun, and let me explore a lot of advanced concepts in React. After many weeks of exploring this idea, the game was in a working state, but had a long way to go to be “complete”.
Rather than continuing to work on it, however, I set it aside. Why? Because my goal (learing React) was complete, and I was ready to move on to learning somethign else. While it would have been cool to add all the features I had thought up, continuing to work on one project wasn’t worth it. I’ve since come back to this concept multiple times in different frameworks and languages, the latest version being in Elm. You can play it here!
You Are the Stakeholder
When working on a professional project, either freelancing or as an employee, there are a number of stakeholders that are invested in the work you’re doing and the end result of that work. This can lead to working on things that you aren’t interested in, or are outright opposed to building.
For side projects, you are the stakeholder! And often, you’re also the only stakeholder, which means that you get to decide what to build, how to build it, and, most importantly, when to work on it. Too often, we push ourselves to work on projects just because we started them, or out of feelings of guilt that we can’t complete something. It is definitely useful to have completed, polished examples of your work for a portfolio, but not all side projects belong in that category.
At work, stakeholders help establish which projects have priority. As the stakeholder for your side projects, don’t feel guilty about moving onto something else, or deprioritizing certain projects. There’s no need to feel bad about side projects, they’re fun!
When I feel like I’m not interested in a side project any more, rather than say I’ve abandoned it, I ship it. It may not be “feature-complete” to everything that I planned, but neither is any production application.
Scoping Side Projects
One of the big draws to technology is this thought that we can build a startup as a side project, and turn it into our main job. While there are a number of successes with this approach, this doesn’t apply to every side project! Not every todo app needs to become Todoist. Not every budgeting app needs to turn into You Need A Budget. Just like at work, it’s important to scope our side projects, so that we understand exactly what a given project should and should not become.
When I’m working on a side project, I try to put them into one of three categories - learning, maintained, and “slow cooker”.
Learning Projects
Learning projects are experiments, with a goal of exploring an idea or learning a new language/framework/library/etc. These may be created to follow along with a tutorial, or just to see if something works in the way that I expect. One of the hallmarks of these projects is that I don’t expect it to last longer than a week or two, and will then be abandoned.
Besides learning and exploration, these projects allow you to plant seeds of knowledge. Sometimes I will experiment with something, abandon it, then later realize that I need to do the same thing I was experimenting with. Rather than start everything from scratch, I can often copy/paste from one of these learning projects, allowing me to move faster and build on my previous learning.
Examples of learning projects include todo apps, using a public API such as the Pokemon API or the Star Wars GraphQL API, or spinning up and toying with a new framework.
Maintained Projects
Maintained projects are created with the goal of becoming a long-running project. Ideally these projects are clean and maintained, and typically small (but not always). When I want to do something to improve or change them, it doesn’t take much to spin up a local environment, even if it’s been awhile. I may point at these projects as examples of things I have done, such as in a portfolio.
The key identifier for a maintained project is that I expect to be coming back to it repeatedly over a long period of time, but is small enough to be finished in a reasonable amount of time.
Examples of maintained projects include my blog, small open source projects, and finished sites/applications that are used by folks on a day-to-day basis.
Slow Cooker Projects
Slow cooker projects are similar to maintained projects, except they may not have a polished, final product in the near future. These projects are the playgrounds of ambition, where the drive to build something new and make a difference somehow. This is where startup-level projects live. It takes time to build something like this, and it’s important to recognize that. Just like using a slow cooker takes hours to make a meal, building a large application, framework, or whatever your idea is will take time. Don’t beat yourself up when something like this doesn’t result in a full-on startup after a few months, or even longer.
For me, slow cooker projects are incredibly exciting, but also incredibly draining. There’s so much going on in life already, and there’s only so much room for large-scale projects like this. When I’m working on a project like this, I don’t limit my imagination or scope, but I allow myself to come and go from the project as inspiration strikes. If I’m not excited about working on a side project, then I set it aside, and wait for inspiration to come back. My goal with slow cooker projects is to enjoy the process, and hopefully have a finished product that I can be proud of.
Conclusion
Side projects are the first drafts of writing, the tuning session of music, and the experimentation phase of science. They provide us a fast feedback loop, and give us the opportunity to try out new ideas and concepts. They serve a crucial role in becoming a developer, and building up or maintaining our skills.
The value of side projects is in how much value they give to us, the developers. Next time you’re feeling burdened with all the side projects you’ve never completed, remind yourself that they all served their purpose. The only person you owe to work on side projects is yourself. Don’t feel like working on it? You just reached version 1.0. Congratulations!
Enjoy your next side project!
Hi, I'm Lindsay Wardell!
I am a programmer, writer, and mother. I work as a Senior Software
Engineer at Mangomint. I write and talk about Elm, Vue, Vite, and other tools that I
enjoy learning about and using.