Your Side Project Is Too Ambitious

I don’t know you, but I know that your side project is too ambitious.

I know that you’ve worked on the project for too long. Weeks? Months?

I know that you keep coming back to it after you’ve got distracted from other projects or personal responsibilities, and found it was ugly and outdated and you wanted to start over.

I know you keep getting stuck on frustrating bugs. It feels like you can spend days on fixing a problem before you get back to actually working on the functionality of your side project. It isn’t how you imagined it would go, where you would have an idea and you’d build the thing and it would be instantly successful.

I know you are afraid to deploy it because it’s not quite ready yet.

I know you have told people about your project, but haven’t really started it yet.

I know your project seems exciting at first but since you’ve thought of it you found out someone else built something similar, so it’s not worth doing.

Your. Side. Project. Is. Too. Ambitious.

I know you got bored with it and stopped working on it, and you feel guilty about it.

I know that you also feel guilty about working on your side project when you have other responsibilities you could be doing.

I know you have started and then stopped and then restarted what seems like half a dozen times.

I know the framework you chose wasn’t as good as this new framework you found out about, so you’ll have to scrap the whole thing because it will be outdated before you even get it out the door.

The reason why I know this is because I have lived it. It’s because your side project is too ambitious.


I don’t know you, but I know you scoped your side project down to the smallest piece of functionality you can think of.

I know you haven’t worked on your project for too long. Hours? Days?

I know that you don’t need to keep coming back to it because you were able to deploy a finished version if it very quickly, albeit with limited functionality.

I know you wrote tests. I know that when you work on it, you don’t have to remember what the functionality you intended was because it is tested. It is how you imagined it would go, where you have an idea and you build the thing and what’s successful is you’re able to get it out the door.

I know you deployed a tiny version of it first, and created a way to continue deploying it continuously as you built it, possibly even with a CI/CD pipeline.

I know you have told people about your project, and given them a link, because it was done before they even found out about it.

I know your project seems exciting at first but since you built the smallest possible version of it, even if someone built something similar, you’ve learned something and have something to show potential employers.

Your. Side. Project. Is. Sized. Well.

I know you got bored with it, but that’s ok, because a minimally viable version of it was available minutes or hours after you started.

I know you feel guilty about working on side projects sometimes, so you started small and got something done fast.

I know you have started it, and then didn’t need to restart it because it was complete soon after starting.

I know the framework you chose wasn’t as good as this new framework, but you don’t have to scrap the whole thing because you have a complete MVP from the outset, and your goal was to learn and have something to show future employers, not build the next biggest thing with the latest technology.

The reason why I know this is because I have lived it. It’s because your side project is small enough to get something useful out the door from day one.

Jared Porcenaluk Handshake Protocol Cover

Leverage my ten years of software engineering experience to find a tech job that matters, get hired, and get paid what you deserve.

It’s all in my book, Handshake Protocol – the step-by-step guide to getting hired as a software engineer.

↓ I'll get a dopamine hit if you share this post