I’ve read some good posts about the importance of having side projects, and I agree, they are important. And fun. I want to talk about finishing your side project. Part of the reason I chose to work part-time is so I can have more time for my side projects. I’ve started many projects. I’ve actually finished only a small fraction of them. Here’s what I think made the difference.
But first, some definitions.
Pop quiz: what’s the biggest danger your PSP faces?
All real dangers no doubt, but I would argue that the real danger your side project faces is abandonment. Why? Because you have limited time, energy and motivation. No matter how enthusiastic you are about it now, your motivation is bound to wane. The more time it takes to finish, the more likely you are to abandon it.
The biggest danger your side project faces is abandonment
But why should I finish it? Isn’t it enough to revel in the joy of creation? Sure, you’ll learn a lot from everything you do, and might have a lot of fun in the process. But I’ve noticed that no matter how much fun I have developing, an unfinished project impinges on my psyche. Like an unrealized dream. Like that girl/guy you thought liked you, and you never made a move, and you’ll never know if it could’ve worked. But the main reason to finish a project is that it gives you more motivation to keep working on it. Circular argument? Perhaps… Let’s see how that works.
I’ve noticed a recurring pattern in my motivation to work on something.
What breaks this pattern, and breathes new air into a project, is traction. When you see your product out there and people using it, you get motivated. And for good reason. When people are using your product, you know it’s viable, and you know it’s worth your time to continue with it. If not, you know you tried and can continue on wholeheartedly to other endeavors. Also, moving on at this stage doesn’t kill your project, because it’s out there, and can start gaining traction with time, while you work on something else.
Your project could reach more success than you think, or even become a source of income. You’ll never know if you don’t get it out there. When making the language learning app Flamingo French, I thought it would be mildly successful. It wasn’t.
But then we had the idea to test out some languages that don’t actually exist, and the results were surprising:
I would never have guessed this when first starting the project. The point is, you never know until you get it out there.
Until you finish your project, you’re likely to grossly underestimate the work required to actually finish it. You think to yourself “it’s basically done, just need some finishing touches”. Those finishing touches can take more time than building it!
After I “finished” building my morning pages app Blurrish (built with electron and vue), I decided to upload it to Apple’s app store. It was already working on mac, so I thought it would take a couple of hours to publish to the app store. It took me a week! (I had to re-write large parts of my code due to sandboxing and app signing problems). I could only have learned this by actually trying to publish the app to the store.
I will paraphrase David Goggins here:
Whenever you think the project is done, it’s 40% done.
You learn this by experiencing it.
Now that we agree that we want to finish it, let’s see how. The most important part of finishing you project is choosing what not to do. The best way to finish your project is by constraining it.
Constrain yourself so you don’t strain yourself
Making a product is a form of creation. Whenever you’re creating, you’re bringing something into existence that wasn’t there before. And when you do that, you need to choose from an infinite number of options. This is called the blank page problem in the writing world. And that’s the hard part of creating.
Constraints are crucial. Having a good set of constraints limits the infinite number of possibilities, and even makes you more creative.
Because we usually perceive constraints as negative, let’s add the greek prefix “eu” (as in euphoria, not the European Union), to remind ourselves that they’re good.
Luckily, we have some constraints built-in to the definition of a PSP, and this is exactly what forces us to be creative. I like naming things in order to remember their importance. And I also like acronyms. Enter SCRUF.
The SCRUF method (never miss an opportunity to invent a new acronym) shows the most important constraints for a side project you’ll finish:
It’s hard to build software. The bigger it is, the harder it is. As developers we have a tendency to under-estimate the time it takes to build something. NOT developing features you think you can develop is one of the hardest things for developers. Take yourself by the scruff of your neck and learn to say no to features! For every feature you add, coding it is just the tip of the iceberg. 90% of the time it will take is in the complexity it adds to the rest of the system, the bugs it will create, the UI problems, etc. Practice feature minimalism and ruthlessly cut away any feature that’s not essential.
The greater the burn rate of each product you publish, the more likely you are to pull the plug on it prematurely. Use free services, or services that will only start costing when your product is generating income. I think 10-20$ per year burn rate is a good number to aim for. Basically only pay for the domain name (if you need it), and use free stuff for the rest. The goal is to have multiple projects, that can run long enough to see if they stick. Maybe you think paying 20$ a month isn’t a lot, but if you have 5-10 side projects running, it can add up. Some suggestions for cost cutting:
DRY - Don’t Repeat Yourself, the most fundamental rule of programming. Maybe even the definition of programming. Don’t repeat your own logic, and don’t repeat other people’s work unnecessarily.
A few suggestions:
Starter project - Spend time on finding a good starter project e.g. Vue project running in a Cordova app with Quasar UI Framework. This will save a ton of time in scaffolding and creating a good dev process.
For me, the time constraint is huge, and it’s a constraint you can easily let go of, because you’re in charge of your own time.
I aim for a product I can ship in about one month - calendar time. This is for first version, and is mainly in order to dictate the size of the project and what features your first version should have. It’s OK (and beneficial) to change the idea a bit in order to fit the size of the project to this time frame.
Why calendar time? Because that’s the determining factor in how motivated you’ll stay. If you have 3 hours a day to work on it, you can do more. If you have 3 hours a week, you can do less. Choose the size of the project according to the time you have to work on it, and keep the total amount of calendar time constant. I’ve noticed that the time frame of a month works well, and obviously this will vary from person to person. Part of the benefit of making things on your own is that you learn to know your own process and how your motivation works.
A point about deadlines: I don’t believe in setting arbitrary deadlines for yourself. This has never really worked for me. You can get into a habit of elimination by keeping a time frame in mind, but an arbitrary date seems redundant. It is a form of constraint though and it might work for you. Try it.
You need to be ruthless to be fast. Cut anything that’s not 100% necessary for a useable first version. Good examples are:
Do you have side projects you’ve never finished? How long does it usually take you to finish a side project? Would love to hear feedback / thoughts :)