The Rise and Fall of the Rockstar Developer

For some time the tech industry was plagued by the term “rockstar developer”. It has been used to mean a programmer who was staggeringly productive, and could sit down at a keyboard and be “in the zone”, producing some complicated piece of software and solving problems that others couldn’t.

It’s a very appealing idea for anyone even remotely interested in coding, and one perpetuated by Hollywood montages of programmers tapping away at keyboards, all to a thumping electronica soundtrack. Most (probably all) programmers spend some of their free time writing code on their own, so it’s tempting to buy into the notion that each one of us could build something incredible while being entirely focused.

It’s also not that unreasonable. Some incredible pieces of software have been written by solo developers, but I’m not convinced it’s the natural state for a software engineer. The subject matter is truly enormous, and evolving at a terrifying pace, so interracting with your peers is necessary just to learn more and to build software that can be used by others.

The result is a notion that started to become dangerous. A rockstar developer is someone that is entirely depended on by a team, and who believes (rightly or wrongly) that they are head and shoulders above their team. Decisions start to go unchallenged, and mistakes go ignored by team members who respond to any quesiton with “because X told us to write it that way”. As the product starts to break down, the rockstar developer in question is inundated with work and (understandably) gets stressed, until things disintegrate (or explode spectacularly). What’s more, rockstar developers are indispensible, and people who are indispensible can’t be promoted and cant’ go on holiday.

Despite all this grim reading, I’ve used the past tense in the above as the industry seems to have moved on. The vast majority of Google search results for “rockstar developer” are critical of the phrase. Software engineers aren’t judged by how many lines of code they write, but instead working out whether someone fits well as part of a team has become a crucial aspect in the hiring process. Teams have started citing “empathy” as a crucial requirement, and while it might seem a little woolly at times, it underscores how much a good application is a product of a good team, rather than one key individual.

That’s not to say individuals can’t do great work. I would still encourage anyone even remotely interested in programming to have a go and do some research on their own. Similarly, engineers frequently investigate things in their spare time. Work is always different though, and when writing software it’s always invaluable to bounce ideas of other people (beyond rubber duck debugging).

If you want a great example of this, the story of Brent in the wonderful The Phoenix Project is a perfect fable. Brent is depended upon by everyone, and quickly becomes a blocker for the team. It’s not that he needs to be fired (far from it – he’s an excellent engineer), but that he is so overloaded with work and depended upon that everything gets stuck.

As the industry moves away from a culture of “rockstars” and key individuals, the environment created by a dependency on cohesive teams is incredibly reassuring.