The truth behind software projects

It’s 3am. You are one commit away from launching your first release of your latest idea. It’s an AI system to help people recommend names for their pets through pictures (clearly, Spot isn’t a great name). You take a swig of coffee. You fix the bug that has been sitting on the top of your Trello board for days now. git add . && git commit -am "Fix issue where AI takes over the world" and you are off. Time to tag this release. This AI will be a hit and pet owners all around the globe can rejoice knowing that the arduous task of naming their pets will finally be over (now only if you had an AI to recommend you variable names). You push the tag and head off to bed. Weeks go by and you continue working on your revolutionary project. You add a feature that allows you to name pet rocks too. School starts. You get swept up with a sea of assignments and presentations. Soon, your baby starts to collect dust as you scramble to finish your assignments. Eventually, school finishes and you heave a sigh of relief. “Finally, I can add object naming too!” you think to yourself. But when you open up the project, you realise that the spark, that allure of the project is gone. You stare blankly at the Trello board of “To-Do” features and begin to see this project as a chore. Those new features and promised rewrites now seem like a hassle. Those surges of dopamine you got every commit, now reduced to a mere flicker. But this can’t happen, right? After all, this was your baby! You had spent an entire semester break building it, raising it. It can’t all be for nothing! What will happen to the poor pet owners? You try convincing yourself that you can power through this lack of motivation. You think to yourself, “Maybe if I just started here, I would be able to find joy in working on this again”. But alas, no matter how hard you will yourself, you cannot find an ounce of motivation to fix that bug, to merge that pull request, to add that feature. You sigh and start questioning yourself. If you cannot finish a mere side project, are you even that worthy of being a developer? But eventually, you find another side project to occupy your time. One that makes your heart race every commit. And the cycle continues.

What I had just shared is - what I believe - a common narrative many developers experience. In programming, we are often bombarded with the idea that side projects are a necessary staple of a developer - that one must have a Github page filled to the brim with open-source contributions and personal projects to be considered a good developer. But is it really necessary? Or are we - as a collective - creating unecessary barriers for ourselves. Is this mindset really good for us? Or is it slowly destroying our motivation and sucking our weekends dry?

In this post, I would like to explore this aspect of the industry and talk about my experiences working on side projects and share some of my personal opinions on it. Now note, I do not claim to be a programming genius nor do I assume that my word is gospel. I am merely sharing my observations and experiences as a developer who was mostly self-taught. More importantly, this post is my way of performing introspection on my past five years as a developer and how much I have grown since then.

Separating the truth from fiction

As easy as it is to denounce the notion of side projects as a parasite to one’s sanity. There are many truths and value that can be derived from making side projets. So, I would first like to explain why I believe side projects are a useful tool for developers.

It is hard to deny that side projects can be incredibly fun to work on. When you find a project idea that you believe in, its siren’s call is hard to resist. You’ll find yourself spending hours on end on it. Your weekends can be engulfed by the pile of features you have planned for.

When someone stars our repository. When Google Analytics reports a new user. When someone makes a pull request. When we get a new issue. It is an undeniable fact that seeing people use what we have built is incredibly rewarding and often times, that drives us to want to work on it more; we now have an audience of users that we cannot disappoint.

Of course, many of us embark on side projects for the intrinsic rewards it presents to us. This fun is usually derived from the prospect of learning something new. Learning how a network protocol works. Learning how a language is used. Learning a new framework. These are all carrots-on-sticks for developers. Naturally curious, we all look for mental stimulation and seek the next idea we can get our fingers on. Side projects serve as a great way to explore different technologies and collaborate with others.

Side projects also offer a way for us, as developers, to view how much progress we have made. Remember that simple chat application you made when you were 16? Now look at you creating web applications from scratch or learning a whole network protocol on your own. These side projects document your journey as a developer and it is refreshing to look back and see how much you have grown through these projects.

A case against side projects

However, while the benefits of side projects are bountiful, it is hard to deny the “downsides” of side projects. Now, I use the word downsides with heavy quotations as I do not believe that these are direct downsides of the idea of side projects itself. Rather, I believe that the downsides to side projects are derived from the value we have placed on them as an industry and how we - as driven individuals - have warped this perception of a side project.

I believe that side projects are unnecessarily prized and emphasised. The naturally competitive environment in tech has caused this idea that side projects are a quintessential component of any developer’s arsenal to become overly emphasised.

It is due to this over-emphasis that many who embark on side projects often develop feelings of guilts when they are unable to see a project through. It has caused the idea of side projects to transform from one of learning and exploration to one of a “do-or-die” nature. Worse still, those who do not devote time to side projects may feel as though they are losing out against others and in turn develop an obsession with trying to “catch up” to them. This also devalues the efforts of those who try at the beginning. I believe that this boils down to the fundamental behavior of humans: competition. We will use any - and every - metric we can get our hands on to compare ourselves against one another. This is also why I do not agree with those who try to micro-optimise their daily lives - trying to squeeze every second that passes to achieve optimal productivity. I was one of those who were also obsessed with ensuring that my every waking moment was meticulously planned to ensure that my productivity remained at its peak. This was born out of fear that the rapid advancements of this field would eventually overwhelm me and leave me in the lurch. However, the reality is, as much as it is important to be driven, we must recognise that there is more to life than an eternal grind to be productive. It is important that we look at the time we are spending on side projects objectively and questioning whether we are neglecting other aspects of our life in pursuit of this “grind”.

This can lead to people developing an unhealthy obsession with creating side projects and working on that “hustle”. While many feel incredibly motivated at the beginning, those who fail to properly pace themselves will end up burnt out. This can lead to a vicious cycle where they push themselves too hard only to feel exhausted, give up, and feel guilty about giving up - spurring them on to try even harder. Burn out - in tech - is one of the worst things that could happen to a developer in my honest opinion. When one’s livelihood depends on their ability to produce good code under a time crunch, a general sense of demotivation can lead one to become careless; introducing bugs into their system. It also diminishes one’s interest in the field and in the worst case, can drive them away from the field entirely.

There are those who also pursue the idea of side projects with the incorrect mindset. Often when I speak to beginners, they often state that they feel this obligation to start a side project because they have noticed that others are doing so. Some start this side project with the goal to become the number one starred repository on Github. Some dive into one because they think that the only way to improve as a developer is to work on side projects. Some also get swept up with the common myth that “side projects == necessity to work in a company” and end up pursuing this belief.

However, what many of these individuals fail to realise is that side projects are not the only measure of a developer’s worth. As alluring of an idea it is that a company will hire you if you have a portfolio the length of a PhD graduate, companies are often looking to hire those who demonstrate problem-solving abilities. So what if you have made 20 APIs before? If you fail to demonstrate the most fundamental skill a developer should possess, you won’t be able to think critically to solve new problems. While side projects can build problem-solving abilities, some may only venture within the range of their comfort zone to try new side projects. In some cases, this could mean never trying any “hard problems” as they do not believe that they possess the capacity to solve them on their own.

It is this over-emphasis on side projects that has placed so much unnecessary pressure on new developers. I have met many developers who have been wrapped in this worry that if they don’t start building a spectacular portfolio right when they start, they will end up becoming a terrible developer. It is sad to see that they place this burden on themsevles when learning to program should be a fun and enjoyable thing.

So what now?

In summary, I believe that side projects are not inherently evil. It is the warped perception of them that our industry has created that has de-valued the true essence of them.

I have been on both ends of the “side project cycle” before. I have been the naive developer who thought having hundreds of followers on Github or thousands of stars on my projects mattered and I have also been burnt out, swamped with school work, and dissatisfied with my perceived notion of productivity.

As with anything in life, the key is balance. Understanding that side projects are not - in any way - sole markers of a developer’s abilities is important. Having a large following on Github does not mean you are a terrific programmer and vice versa. Learning to appreciate the learning process, rather than working on something for the potential rewards, is an important aspect of life and moreso in this culture where developers often try to one-up one another with false measurements of success. In the end, what you work on should matter to you. You can build something to benefit others, I am not discouraging that, but you must bear in mind that at the end of the day, the one who benefits most from it should be you.

I think we have to look at each project objectively. “Have I learnt something about myself, this technology, or programming in general?” If yes, then I believe that you have already benefited greatly from it. Whether or not the project is “failed” or “incomplete”, as long as you have learnt something along the way, I do not believe that you should belittle that effort.

So go out and build something that inspires you! Work on the project that gets you excited. Explore technologies that you are interested in. Don’t worry so much about the perceived value of the project you are embarking on. This is YOUR journey, so enjoy it to the fullest!