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.
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.
4. Find your source of ambition
Committing for a side project is difficult. Considering the stressful modern-life routine, self-motivation is the hardest thing about side projects.
Habits are super important here, but losing momentum is inevitable. Be aware of that.
This is why having “ambition boosters” are important.
For me, talking with friends about my side projects gives me the boost I need. When someone responds with “wow, that sounds really cool, I’d use that” — I wanna stop whatever I do now, and continue working on my side project. Like, right now.
Find your fuel. It can be talking with your spouse or friends about the project, or reading about inspiring people, or maybe meditating. Public commitment has a psychological effect that can be leveraged as well. Hell, hang a Chuck Norris poster above your bed if you need to. Do whatever fits you.
The important thing is keeping up the good work. Even in difficult times when you think of quitting, remind yourself why you do this.
“Who you are tomorrow begins with what you do today.”
— Tim Fargo
5. Avoid Burnout with a Daily Routine
It sounds like an oxymoron, right? Let me tell you a short story.
“You’ll work on the side project 4 hours a week, no excuses!”
— Me, 18 months ago
4 hours a week sounds legit. The challenge is spanning them correctly.
At first, I had 2–3 sessions of work each week, 1.5–2 hours each time. It was great — I felt energized.
Then I had to skip one week’s work. I felt so bad about it, that I worked at that weekend for 5 hours straight.
Afterwards I felt burnt-out, and frustrated for the situation. A vicious circle has started. I avoided the side project on work-days, on the expense of coding marathons on weekends.
I quickly grew tired.
I realized something has to change.
Wait, you were talking about AVOIDING burnout…?
I’m getting to it.
After googling for ideas, I was lucky enough to stumble upon Ulisses Almeida’s great article about Long projects in your free time.
In the article, Almeida inspects some important aspects of long projects. One of the things that affected me the most was the following paragraph:
(…) When you miss a week, it’s easier to lose motivation because it’s harder to recover from that. If you work a little bit on your project every day, it helps you to keep progressing. One day that you miss, won’t be a huge impact on your routine.
This article has changed my perspective completely about how I should work on side projects.
I’ve changed my commitment. By committing to a daily routine of 30 mins per day, skipping a single work session wasn’t too bad. I knew that the next day I’ll be working on the project.
Switching to a daily routine has been great for me, and I full-heartedly recommend it. A “daily routine” might sound startling at first, but it is achievable, and it will quickly pay-off.
By the way, if you’re looking for a way to track and build your daily routines, try Loop — Habit Tracker. It is an awesome app that helps you developing good habits.
6. Have milestones
After 9 months working on the side project, I’ve started working on a testing library.
I was in the middle of working on the original side project. Uncommitted changes, TODOs scattered all over the place… a bit of a mess.
Although I am usually a tidy person, I left the project this way since I didn’t want to “waste time”. I thought I’ll get back to it in two weeks or so.
In the end, I’ve spent about 4 months working on the testing library.
Afterwards, I found it difficult coming back to the original side project.
It felt like visiting a very old friend. Things got awkward, I forgot some details. I wasn’t sure how to “break the ice” and progressing to a positive direction. It took a while getting over it.
If I had left the project in a proper manner, without “half-baked” features, coming back to it would have been much simpler.
For that reason, I suggest setting small milestones for your longer projects. These can be used both as goals and “exit points”.
When reaching these milestones you have two choices.
If you enjoy the project, you can continue expanding it and adding more features.
But in the inevitable case where you stop enjoying the project, it’s best leaving it in a good condition, and not in the middle of the work. That’s where having milestones are really handy.
Having smaller milestones lets you having “exit points” from the project, while still being able to have some working product in your hands.
7. Retrospect, and retrospect often
I’m sure that I’ve raised a few eyebrows right now. Side projects should be fun — why ruining it with a tedious task as a retrospective?
Because time is your most valuable resource.
When working on longer projects, working efficiently is crucial. Stopping every once in a while to think about your work, can raise awareness of your progress.
Start with a frequent retrospective to increase efficiency on an early stage. When you feel you have found your way, reduce the frequency.
Make it short and summarized. The goal finding way to improve your work. Ask things like:
- Did I meet my goals for spending the time on the project? If not, how can I improve it? For example, work on the side project when commuting (if possible), leave work 30 minutes earlier on certain days, or waste less time on social media.
- Am I working efficiently? For example, am I wasting time on testing POC code? Am I investing too much time on linting or code coverage? Think of your work in the last period — how can it be improved?
- Am I meeting my goals? Do you feel like you are on the right track? Or are you working on “auto-pilot”, without knowing your destination?
Conclusion
I have made many mistakes while working on side projects. Also, I didn’t understand the importance of working efficiently. I wish I knew 18 months ago the things I mentioned here. I hope this post will help someone with her or his side project.
Do you have good tips for side projects? Please let me know by commenting below!
Did you find anything interesting in this post? Claps will be much appreciated.
TL;DR — Tips for side projects
- Any project is better than no project. Find a subject and commit to it.
- Commit to a daily routine.
- Find what drives you. Use it as a source of ambition.
- Write milestones as goals and “exit points”.
- Focus the right things. Do not spend time on longer tasks if they aren’t necessary.
- Premature optimization is a greater pitfalls than “real-life” projects.
- Retrospect. Start with a frequent retrospective.
🕵️♂️ Psst… If you enjoyed this, follow me on Twitter (@omril321) — I tweet regularly about cool things I learn.
