Recently, I discontinued my work on a side project I’ve started 18 months ago.

Doesn’t sound like a big success story, right? I thought so too.

But looking back, I realize that I learned a lot of things, techniques and tools that will help me next time I’ll start a side project. In this post, I've gathered some of the methods and conclusions from the past year and a half.

If you want to start working on a side project, or willing to become more efficient — this post can help you.

If you’re the TL;DR type, you can find a summarized list at the end of the post.

1. Finding a Subject

I hear a lot of people saying they want to start working on a side project, but don’t have “good-enough idea”.

Instead of struggling with finding the perfect subject, try googling for ideas. Your project doesn’t HAVE to be original. It just has to… be.

It is possible that you, like me, are afraid of starting a long project without being certain you will finish it. Countless of doubtful questions come up with each mildly interesting idea:

What if I won’t like the subject?

What if with time, a marvelous idea will come, and I will want to switch projects?

What if…? what if…?

The answer is simple.

You don’t have to wait for a good idea. You don’t even have to wait for an average idea. Just start working on your best current idea.

“Better to do something imperfectly than to do nothing perfectly.” — Robert H. Schuller

If you’re sitting with me in the Perfectionist-Anonymous circle, and afraid of committing to the wrong project, I recommend reading the “Have Milestone” section below to fade some of your concerns.

2. Focus the right things

Starting a side project gives an amazing feeling. Unlike the work we get paid for, on side projects we can do all the things we’ve dreamed about. The sky’s the limit.

This makes focusing on the wrong things a very easy mistake to make.

Having wings and flying are two different things. Working hard on a side project won’t necessarily get you to your goal.

When I started the project, I was determined to write high-quality code. I quickly added code coverage, linting and cool webpack plugins.

I thought I’m keeping my code in high quality. In reality, this decision made me waste time on irrelevant subjects. Keeping the code coverage high, meddling with linting issues, making some webpack plugins work… these dwarf next to having a working project.

Some may argue that code quality is important, no matter what.

I agree, but moving to your goal is even more important. For example, if you write a minimal POC, code coverage is less important. Obviously, you can still write tests — but you don’t HAVE to.

The point is remembering what’s important and what’s not. Be aware for when you are wasting time on things that do not contribute to the project’s goal.

Here are a few tips that can help you staying focused:

Make a short list of goals for the project. For example: “making a library that does X”, or “learning how to work with framework Y”, or “improving my testing skills”.

Avoid spending more than roughly 30 minutes on something that does not contribute to a goal.

Have two backlog lists. The first is for features you would like to add to the project. The second is a “technical debt” list, like missing tests, poor-quality code, and so on. This will reduce the fear of forgetting a good idea.

When you finish for the day, write a note to yourself that says what should you start with in the following session. This will save you precious time remembering what you wanted to do.

3. Beware of premature optimization

Thinking about more things I’ve done wrong, I understand I was too quick with optimization. “Premature optimization is the source of all evil!”, I know.

In the beginning, my project had a complex algorithm that took ~23 mins to run each time. I felt like I HAD to optimize — It was impossible using the application. It was worthwhile spending 2 weeks of optimization just to go down from 23 mins to 2 mins, right?

Wrong.

The result of the premature optimization was a highly-optimized and highly-complicated algorithm. It made future development much harder.

Having a working, slow application, is much better than having no application at all. Especially in the context of side projects.

If a certain code block is slowing you down, and you don’t want to optimize it yet, find a way to work around it. For example, use fake data combined with Storybook, or use a fake implementation.

Optimizing after having a working project, is better than optimizing too early. Improving an application after building it gives you a holistic view. This way, you make each decision while completely understanding all side-effects. Premature optimization has side effects you don’t know yet.