Why Every Developer Should Build a Side Project
Side projects are an important part of the developer lifestyle.
Join the DZone community and get the full member experience.Join For Free
I would like to encourage every developer to go and build a side project. There are so many things to learn in building and launching a side project, not every developer gets a chance to do them in their day job. I am not talking about technical challenges, but the process and discipline it takes to build a successful side project.
You may also like: The Benefits of Side Projects
Getting it to Completion
Every developer I talk to has an idea that they plan on finishing someday. Most of them have an actual repo with some code halfway done. If you ask them when they started, the answer is usually in months or even years. The number one hurdle in doing side projects is finishing it. If you are telling yourself you don't have time you also know you are lying at some level. Here are some of the tips to get it done.
- Don't be a perfectionist — when it comes to side projects developers are hard on themselves. They want every line to be so perfect and clean, they spend most of the time refactoring. Also the temptation of trying the latest and greatest. When I started StoryTime halfway through I started porting it to typescript and switching over the DB to Postgres. Both are new to me and I realized my productivity went down by half. The hardest thing to do was to reset a few commits so I can go back to Flow and MongoDB, but I am glad I did that.
- Nail down your MVP — I can't stress this enough. Every product has an MVP. Find it and write it down. The simple test to decide on MVP is to ask a simple question. If I don't implement this feature and someone lands on my site will they still understand the value it provides? If the answer is yes, it's not MVP.
- Take a break when you know exactly what the next steps are — This is a simple technique I used to overcome procrastination. Not my original idea, but read it somewhere and it works great. Don't stop your work after you complete a feature or bug. Stop at a point where you know exactly what file you are going to open next and what lines of code you are about to change. That way when you come back instead of getting distracted by articles on DZone, you will jump right back into coding.
- Remove all friction in the product — The first thing you need to do before asking for feedback is to remove all the friction so people can use it to provide feedback. In StoryTime.dev you can start creating stories without creating an account. I think that gave me an opportunity for many to try it out and give quality feedback.
- Collect feedback in one place — Forums like hacker news comment section is a great place to get feedback. Introduce yourself and ask for feedback. You won't be disappointed.
- Prioritizing feedback — This is where you will wear the hat of a PM and go down the list of feedback and decide which one to work on first. After this exercise, you will start to appreciate the PM at your day job more. Not an easy task and very product-specific. A general rule of thumb — Bang for the buck.
Launch it Again and Again
There is no single launch event for your product. There is a great video from a YC startup school that goes into detail on the process of launching again and again. Find where your audience is and make sure they get to see what you built. This is where you will wear the marketing hat and start looking around for your audience and find creative ways to reach them. If you build a developer tool like https://storytime.dev, one of the things you can do is to write a helpful article on lessons learned and kindly ask DZone to publish it.
I hope you find this article useful!
Comment your favorite side projects below!
Opinions expressed by DZone contributors are their own.