Dreaming up, planning, designing and building side projects often fosters a fresh, rejuvenated atmosphere of creativity, curiosity and possibility around a team. As a senior engineer, demonstrating that you value exploring ideas outside the domain of your direct focus encourages others on your team to do the same, to the benefit of all.
Software teams that restrict themselves to thinking only about their current project are apt to stagnate, fall behind and burn out. Teams that are lead to invest even a small fraction of their time investigating new tools, fresh concepts and emerging practices are much more likely to find a sustainable balance between productivity and fun.
This is especially true if you work on problems with a short information half-life, like web development. Even if your current technology choices are ideal, browsers and web protocols are changing rapidly around you, so you’re eventually forced into architectural changes.
Side projects are a great place to explore interesting problems with little risk. Unlike a work environment, you can abandon a project part way through, as there is no expectation of finishing. I store a lot of my projects in Bitbucket, because they have free, private git hosting, so I can choose if and when I want to reveal the work to the rest of the world.
Some companies like seeing job applicants have side projects, but these are typically hard to evaluate directly (does that project on your github even run?) The real value comes from the knowledge you acquire during the effort.
Once you get far enough with a project to write or speak on the subject, you can demonstrate thought leadership. If you’re in technology leadership this may increase the number of people applying for positions on your team, but more importantly, it makes joining your team much more desirable for people who are looking to grow.
Not all side projects are code - configuring and hardening a virtual machine with Wordpress is a fantastic learning experience. If you set up a blog, writing essays on your findings is a good personal growth exercise. I know a couple people who work for AWeber, and use the email marketing software to explore new ways for businesses to interact with customers (e.g. "100 words" and "Weekly Coffee" ). If you prefer to explore open source to “give back”, there are many small libraries with burned-out creators who’d like a reprieve.
In writing this piece, I consulted my peers and discussed lessons they’ve learned:
Building a project from scratch forces you to think through architectural decisions that are typically made for you. You will likely find that you can spend a lot of time on problems unrelated what you really want to solve (e.g. build tooling, user account management). Each of these problem has a seemingly infinite number of solutions. This has forced me think through the trade-offs inherent in architectural decisions, and improved my time management skills.
If you write code for exploratory purposes, your coding style will likely be a moving target, and you’ll find that you periodically step away from a project, and later return, likely forgetting parts of what you did. After a few months, this is a pretty accurate simulation of what it’s like to work on a real project - varied coding styles and potentially unfamiliar functionality.
I found that documenting problems as a I go helps me later - my blog provides me with auxiliary memory, which I consult regularly to refresh my memory on certain tasks.
Should you wish to write, there are many “weekly” email newsletters (JavaScript Weekly, and so on) - these always need high quality content and have large readerships, so if you want to work on essays for talks, these are good target audiences. There are also syndication sites that are friendly to software developers writing about their work - e.g. DZone, Dev.to, or the sideproject subreddit. If your friends or peers are also subscribed to any of these, it looks really good when your work shows up.
In some industries it is difficult or impossible to having public facing projects, because of security or IP concerns. If you choose to work on side projects, it’s important to give some thought to what you want to achieve, and how you will work within the constraints and opportunities at your disposal. Done well, these can be a great boost both to your career, and to the culture of your team.
Gary Sieling is a Software Architect at Wingspan Technology, and built a side project that lets you search over 150,000 lectures: https://www.findlectures.com, and an email list with curated talk recommendations.
Top comments (3)
I'll add that if you're doing a side project mostly for resumé building, you're gonna have a bad time, period. There are a lot of ways to build a resumé, and you're better off doing things you enjoy. If it happens to help your resumé, that's a major bonus.
I agree and I'd add that side projects that have no technical aspect at all are great for a) mental health and b) innovation. Venturing further from the code will give you a lot of insights as to areas in the world that might be fun and useful to add code to once you have steeped yourself in the world.
Great points, thanks for the reply!
How are the results sorted?