The year was 2011. I already had a few years of experience building backend systems and felt ready for something else. Don’t get me wrong, writing code that processed requests and deposited them elsewhere was interesting and had fascinating challenges, but I wanted a project I could feel, touch, and break. Something I could see work, rather than just looking at a text on the screen and hoping that everything works, with a frontend that would help me learn about UI.
Now, I could ask my manager to shift to another team, but we didn’t have any open UI tasks to work on in our group. Moreover, I didn’t want to commit to a change before testing the waters and seeing if frontend work was fun.
That's how my first side project came to life. Many more would follow.
The call for side projects
I need to do new things when I want to learn new things. The knowledge just doesn’t stick when I watch lectures or copy and paste someone else’s code. It’s not always possible to extrapolate from the example to the general principle or understand the full complexity when everything runs smoothly in someone else’s environment.
As we know too well, implementing technologies in software is never about just copying and pasting. When learning new concepts, you need to understand mental models, tool functionality, real-world implementations, and debugging processes—among many other things. Controlled environments such as classes help, but they can only go so far in giving you practical tools and methods for the handling of real-life scenarios.
That’s why, when I wanted to learn how to build a frontend application, what I did was to build an actual application. Specifically, I focused on Android for two reasons:
- I knew Java and didn’t want the experience to be overwhelmingly hard.
- I had an idea in mind for an Android app that I would want to use.
These two elements are crucial for a good side project. It shouldn’t be frustratingly hard because the point is to complete it, and you should have an actual use case while being open-minded about ways to achieve it.
Why side projects are so awesome
These days, being a software engineer is about much more than coding. Some would even argue that writing code is the easiest part of the job. You also need to understand the product, users’ needs, and ways to provide the most value with the resources you have. That last part is why we work with 3rd party services a lot, integrate existing libraries and try to pick the right tool for every job—all of which require skills beyond code.
Complicating matters even further is the need to work with other people, making communication and collaboration an integral part of the job. We need to know how to raise flags, ask questions, give and receive feedback—all while learning new things.
Side projects are the best way to get out of your comfort zone and push everything I’ve mentioned above to the extreme. You’ll need to put the hats of a product manager and a designer, do QA, manage the project and support it. You’ll set priorities, compromise, ask others for help, and get involved in open-source projects if you need something from a 3rd part library. Hell, you’ll be able to do marketing and sales if your product matures enough.
And since, as I’ve already mentioned, a side project is something you should want to build, it’ll be easier to go the extra mile and put in more effort than you would on someone else’s project.
What’s wrong with side projects
Much has been written about the graveyard of side projects. It is, indeed, a huge one. For every side project that came to life, many have been abandoned or put on indefinite hold (which is the same thing). For some of them, premature death was inevitable. For others, it could’ve been avoided.
Remember how a side project shouldn’t be too hard? It’s not always easy to tell whether you bit off more than you can chew before committing. You can’t always know if you’re using the right tools, and sometimes hours upon hours of work can go down the drain.
But while unexpected complexity isn’t always avoidable, you should prepare yourself for it and the many other things that will most likely go wrong. For every exciting task, there’ll be a tedious one. For every shiny innovative feature implemented, a stupid bug that takes hours of your time to solve will ruin your day.
Technical problems aren’t the only ones you might (and likely will) face. Working on a side project can be very lonely. It’s often hard to keep the momentum going, especially when it’s not your main job and the progress is slow.
Moreover, we need to remember that people usually start a side project to learn new things. It’s often connected to their day job and their career in general. And things change. Priorities, free time, your professional interests—many shifts can herald the doom of your side project.
Is It Worth The Effort? Absolutely!
Yet, for all that can go wrong, you shouldn’t underestimate the importance of side projects. Thanks to my first one, I accepted a job offer from a start-up. Since then, I have tried to make sure I have an active side project at all times. And while I’m currently failing at this, as Wilco takes all of my time, I can’t recommend the practice enough.
Side projects helped me learn Android, Computer Vision, Node, React, Firebase, React Native, Webpack, and numerous other technologies. I put myself in the shoes of UX, Product, Marketing, Sales—furthering my understanding of their value to the team and the challenges they face. At the end of the day, I genuinely believe that maintaining side projects made me a better software engineer.
