Why it's okay to never "finish" your side projects

Side projects are a near-ubiquitous thing that developers of almost every background tend to have. We've all heard stories about how side projects that were intended to solve small problems their respective authors had made them millions^[1][2].

A frequent sentiment I hear from developers all experience levels is the number of unfinished side projects they tend to have. This is such a widely understood feeling in fact that the consistently excellent CommitStrip webcomic published a strip on the issue.

The general flow is to start a super exciting thing, and after a while, it quickly loses its novelty and you move on to the big exciting next thing. Unfortunately, with all the major side project success stories and literature focusing on discipline and productivity^[3][4] or lack thereof as the cause why projects don't see completion, it can feel like there's an implicit expectation to finish whatever side projects you start. I've seen frustration behind this expectation this used as a rationale to avoid starting new projects. To paraphrase a recent conversation I had.

"Ugh... I already have a lot of unfinished projects. If I start this it's probably going to end up in that pile and I'm going to feel bad that it's going to go nowhere..."

If you can relate to this, you aren't alone. While I'm not arguing against the benefits of working on projects to completion, I do want to make a case for why not completing your various side projects is not necessarily a bad thing.

Why do developers have side projects?

To dive into this I think it's important to do some introspection to understand why we build side projects in the first place. While this is largely a subjective question with more valid answers than there are developers, a lot of the literature on the subject tends to converge on a few broad reasons^[5][6],

1. Personal Growth - These are the classic learning side projects. They are playgrounds to learn new languages and frameworks. These are the trial runs to learn to do things in new and interesting ways in a greenfield environment as opposed to the struggle of working within the constraints of a legacy project.
2. Creative exploration and combining interests - These are typically the side projects which exist purely to realize some kind of passion. For example, a developer working in FinTech may have a passion for games and may choose to spend some downtime building games in Unity or some other platform on the side. Working these types of projects to completion would be excellent. However, there is a therapeutic component of fulfilling and exploring an interest at play here.
3. To capitalize on an opportunity or solve a problem - These are the side projects with a very clear goal in mind - "I want to make this because it solves some problem". This is typically done with technology you know well and understand. What is favored here is the speed of completion as opposed to exploring the novelty of learning something completely new.

As a result, it's valid to conclude that,

The goal of every side project isn't to deliver software.

Knowing that the goals differ based on the type of project, it's inevitable that once a project's author gets what they want out of a project, the novelty wears off and they naturally move on to the next novel idea or experiment.

Being aware that delivering a complete product is not always the goal means that you are now empowered to maximize the return on the true aim of the project.

For example, If the primary goal was learning, did you learn something? Or sometimes more importantly did you learn ways to not do something. Perhaps documenting the result of your learning for future reference or publishing the result of your creative exploration "as is" with no warranty of any kind^[7].

Okay, but how do I finish the projects that I want to finish?

Sometimes you do have projects where the primary goal is completion.

For side projects where the end goal is delivering some kind of product to users. It's worth approaching your side project with the same level of organization you would a real project with a clearly defined scope, deadlines, and deliverables.

1. Keep it small, and define your deliverables upfront - In a real project, the scope of work is usually defined before the first line of code is written. You may want to set up a project tracker or Kanban board to help visualize. While this might seem like overhead upfront, it's instrumental in keeping yourself honest and accountable for what work needs to be done and how far along you are in hitting your goals.
2. Prioritize the most important features - You always want to work on the most valuable problem first and constantly reprioritize to make sure that you are always working on the most important thing
3. Stay the course and release as soon as possible - You want to release your project once you have something viable that others can get their hands on. It might feel incomplete however you want to trust in the scope that you defined early on.