There is often a substantial difference between a new developer who works on side projects and one who doesn't. But how do you make sure you're working on the right side project?
It is often trivial to tell the difference between a new developer (with less than three years of experience) who works on dev-based side projects and one who does not.
In general, when comparing developers who have the same experience (in years/months), I've found that developers who consistently work on side projects develop the following characteristics:
I use the word characteristics here intentionally, because these things aren't always good. A new developer's energy must be focused for these changes in character to become benefits for the teams on which they work. For example, working faster can be a great benefit, but without an attention to detail or the bigger picture, it can also lead to more bugs. And as nice as it is to have an eager developer that wants to try new tech, it's difficult to be successful when constantly reinventing yourself.
Putting these two ideas together means that a developer who explores new challenges through side projects, while also harnessing their growing capabilities, can be an extremely valuable developer to any team.
But what type of side project is most valuable for a new developer? There are tons and tons of choices out there in the wide world of programming, but here are a few examples:
Any of these options can be built alone or as part of a community/team. That is a very important decision to make. And, like I always say, I think the answer is to find a balance. There are benefits to gain from working on a team (especially if you can lead the team), but there are also substantial benefits that can come from building projects on your own.
Let's take a look at some of those benefits.
I find side projects in the developer world to be beneficial for four main reasons:
Side projects, especially solo side projects, force developers to spend more time trying to solve problems instead of immediately asking for help. There are great resources out there to help us dig out of holes—Stack Overflow, for example—but the answers aren't always immediate. Without the lack of another developer readily available to help, it behooves the side-project dev to spend more time trying to solve the problem. And when they can consistently solve problems on their own, they will start to feel equipped, and will very quickly pick up speed.
The developer on a solo project has to solve all the problems. Most junior developers don't build green-fielded applications on their first day. Usually it takes quite a bit of time for a developer to get to that point in their career. But, at home, anyone can do that on Day 1. Anyone can build any application they want. And when a developer takes what they learn from that experience back to the office, they'll quickly become more versatile in the types of problems they can solve because they have experience thinking and solving problems at a systems level.
Whether part of a group or working solo, side projects are a haven for exploration—for learning new languages and frameworks. When dealing with a difficult problem during the day job, spinning up a quick side project within the context of that problem may provide the extra boost needed to solve it. On the other hand, if there's an interesting new language or tool out there that the team has been talking about but hasn't explored, a side project can be a great space in which to create a proof of concept and share it with the team.
When working on a team on the side, new developers can provide themselves the chance to lead a project earlier than they may have been able to during their day jobs. All there is to do is to find a few willing participants and then go after a common goal.
I've written about "The New Developer" generically and in the third person here on purpose. You don't have to be that developer. You don't have to work more than 40 hours to be good at your job. You can write code during the day and spend your early mornings, evenings, and weekends with your kids, dog, playing video games, hanging out with friends, or doing whatever brings you joy. That's totally fine. You can build a solid career in the programming world without working yourself to death.
But, the reality is that you're going to progress slower than your counterparts who are passionate enough about what they do during the day to also want to do some extension of that outside normal working hours. Yet that developer must stay balanced to be successful. A dev working an extra 20 hours per week on a side project has an opportunity to advance faster than one who doesn't. They also run the risk of burning out, which drastically slows down progress (I should know, I've been there many times).
The key here is that side projects should be unique. They present the opportunity for a creative shift that many day developer jobs don't. You can benefit from those opportunities if you spend only a couple extra hours every week exploring them. The point is to explore, not the extent to which you explore.
So, free up a little time in your week when you're not doing something that's bringing a ton of value to you. Spend that little time on a side project. Then, watch your work during the day begin to evolve your career for the better.
Three developers—The Good, The Bad, and The Ugly—each handle change in their own way. What does it take to become The Good, to ride off into the sunset with the gold?