Professional software engineers sometimes have side projects. One of the uniquely empowering aspects of writing software for a living is that you can build software yourself, in your own spare time and at extremely low cost, and that your work can still be useful to others. Even beyond the utilitarian angle, side projects are a mechanism for learning, using new technology, and even networking; coding schools, for instance, routinely advise beginners to work on their own side projects to make themselves more attractive to future employers1.
In fact, it was only a few years ago when it seemed like engineers were summarily discounted if they couldn’t show off a bunch of side projects and Github profile activity. For the better, people eventually realized that many excellent engineers don’t always have the time to code for fun in their spare time, and job candidates don’t get penalized as much for not engaging in side projects. If anything, there’s a ceiling to how much side projects help professional software engineering careers, though aficionados may find out the hard way.
Side projects usually aren’t a negative signal—they show that an engineer is passionate about their craft, that they have the ability to pick up new technologies and demonstrate autonomy and self-sufficiency. Developers get to show off their coding style, attention to detail, best practices, and sometimes even their ability to evolve the project and product. It is, by most counts, a better channel to surface useful signals for measuring engineering prowess than the typical software engineering interview.
The ceiling appears when those attributes are necessary, but not sufficient, to build complex the types of complex software which requires engineering teams and organizations. At scales beyond the individual coder, collaborative factors start to gain importance and eventually dominate: communication, architectural design and influence, and aspects of project management become the key skills that align a group of engineers and drive a big project forward. Staff and principal engineers have an easier time crossing over into management in part because the skills—how to have impact via technology—start to overlap.
So if those are the requirements to professional advancement, it’s not a surprise that most side projects—singular creations of utility and exploration completed during one’s spare time—wouldn’t provide the opportunity to exercise those muscles. I can think of one notable exception, however: building or even just maintaining a popular open source project with multiple contributors requires a ton of collaboration, arguably even moreso than most corporate environments2. Otherwise, the easiest way to get that experience is, well, by joining companies with sizable engineering teams collaborating at some scale.
To be clear, I’m not suggesting that senior engineers can only be molded in the factories of Google, Facebook, et al. I’ve had the privilege to work with some really excellent engineers who were able to scale with their startup’s growth, and picked up those collaborative skills as their teams got complex enough to need them. I’ve also experienced engineers who had impressive side projects, but really struggle to integrate themselves to the dynamics of a team, which ended up capping their capacity to make meaningful technical contributions.
