From my first days as a professional software engineer, I always spent some time in developing my own side projects. While some side projects doesn’t make sense (like the tweet above), I saw that side projects were a huge benefit for my career, so I decided to write some of the lessons I learned of how to maximize the effect of side projects.

Go live!

Yes, you heard me… Go live with your side project! Recently I built my challenge web site, (www.mypopchallenge.xyz) and while the UI is not very impressive, I found very interesting challenges when it came to deployment. The fact that my 1 year with free tier at AWS is over made me write some scripts to synchornize between my now.sh instance and Netlify deployment so I can use them both and keep my expenses to the minimum.

Going live is not just about publishing your app to the app store or deploying your website to the web. It can be publishing a library to npm or even just open sourcing the code so people can see it, use it and learn from it.

So here is my first suggestion — Go Live!

Don’t try to make money out of it

When you’re trying to make money out of your app, you start to get crazy. You can imagine yourself in piles of money and you are working towards it. Isn’t that good? I think it is amazing. It is a spirit of entrepreneurship and lots of good products started like that. But this is not a side project. You definitely will learn a lot but when you start to see money out of it, it will be very hard to abandon it, which is sometimes the right thing — to concentrate more on your daily job or to start a new side project with a new technology you want to learn.

And here is my advice — build side projects for fun, not for money.

Learn incrementally

So you have an idea: it’s the best ToDo app the world has never seen… You heard about this amazing front end framework that has 1 billion stars on GitHub and the server must be with that data transfer hot framework, you also know 3 cool JS libraries that you must try, and you want to try your skills as microservices architect. Sounds a lot? It is a lot! side projects has the nature of being fuelled solely by motivation only, and as such you need to see results fast, or the motivation will blow away for the next cool idea. And guess what, in a month you will have another half baked repo with 2 microservices, half of data layer and a piece of front end.

My advice — choose one new technology at a time for your side projects.

Work alone

90% of a problems in a software development team are communication problems, the rest are problems that people can’t communicate well enough to explain. When you add a members to your side project team, you need to spend time on communication. And while communication with other people is awesome, you won’t get the benefit that you want your side project to give. (I’m not coding on in code communication methods. All of my side projects documented and have full Readme files)
If you don’t want to explain why you decided to change the technology stack, or to spend 25% of your time on syncronization inside the team, leave it alone.

My advice — Side projects are exactly the time to enjoy pure experience of coding alone which is the experience most of us used to love when they choose to learn how to code.

Note: sometimes when the scope of the project is too big, you already went live and you want to go faster or you just started your side project so you can learn how to communicate better, it’s actually make sense to work together.

Code together

The fact that you’re working alone, doesn’t necessarily means that no one should see your code. When ever someone ask for my advice to improve I’m telling him this advice — “Find some one to review your code”. When I write a critical section code, I will always show it to someone. I ask a lot about the design and I am trying to get as much people involved in a friendly, advising position. If you don’t have anyone to do that for you, there are a lot of people out there that will be glad to help with that. (fun fact — I never got bad comments on my code when friends review it. I guess there is a correlation between the willingness to review someone code as a favor, and having good programming skills)

My advice — share your code as much as you can to get feedback and become better.

Conclusion

Side projects are fun. I love the feeling of showing some of my work to people and the excitement to see people interacting with my products. I learned a lot from my side projects and the lessons I gave above are highly optimized to learn. If you have other experience or another lesson that you learned from your side project, please write a comment about it. Also if you want to share your side project I would love to see a link in the comments.

This is my first cross-posting from Medium. I hope you would like it, and I hope I found a new place for positing my thoughts.