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.

Software Development with Empathy

I’m hoping this will be the first in a series of posts about some recent trends in the way software is developed, going beyond the raw technologies involved.

Around nine months ago I was fortunate enough to be working with a team at Pivotal Labs – a consultancy (although I suspect they might baulk at the term) specialising in Extreme Programming which works with clients to train engineers in pair programming and test-driven development.

One of the core principles by which Pivotal operate is “Always be kind”, which might easily be dismissed as comparable to Google’s famous “Don’t be evil” mantra. At its root is the concept that a team functions best when there is a sense of empathy. As one team member phrased it to me: “egos are left at the door”.

It’s worth defining what this actually means, as it’s very easy for companies to get lost in a series of platitudes in an effort to change its culture. Empathy means taking the time to listen to everyone an seeking to come to a solution to a problem as a team, and seeking to understand colleagues. Adopting empathy as a core principle for a team involves recognising that no team member is capable of doing all of the work – and if they are there is something fundamentally wrong with the team structure.

Crucially, empathy does not just mean giving way to the loudest voice or ignoring bad work. I’m currently reading the excellent book Radical Candor by Kim Scott which describes “ruinous empathy” – the idea of skirting around an issue so it isn’t addressed. Building a team founded on empathy involves caring about people, and caring about how they do their work and how they learn.

It’s a very difficult balance to achieve, but an important one. Empathy might seem like an obvious requirement, but historically it’s been discarded in favour of “rockstar developers” – a fantasy that a genius-level programmer can sit at a terminal and build brilliant software provided they are left undisturbed. The balance seems to be tipping the other way, which is good news for all engineers.