No More Rock Stars

When I was seventeen I bought a stack of Lou Reed records. I didn’t really know that much about Lou Reed but there was this girl. And she really liked him. And I really liked her. So I needed to get into Lou Reed quickly. I started where everyone starts with Lou reed - the 1972 classic Transformer - by any standards an impeccable piece of work with its heady mix of brash sexual metaphors and delicate vocals. Then I explored forwards through his catalogue and backwards into Velvet Underground territory. An area I was more familiar with having loved Joy Division’s cover of ‘Sister Ray’ about a transvestite smack dealer and Orchestral Manoeuvres In The Dark’s 1980 cover of ‘I’m Waiting for the Man’ about a $26 heroin purchase.

As it happens my musical tastes lay more in post-punk new wave than they ever did in the vaguely camp style of glam rock espoused by Lou Reed. Which was just as well because the girl I liked turned out to be a Neil Young fan.

At some point I guess you have to like what you like, not fake liking what people you like like. For a while though Lou Reed took his place in a succession of heroic icons on my bedroom wall.

A sentiment I heard a lot during my dalliance with Lou Reed was:

Oh yeah. Lou Reed is awesome but you know he’s an asshole, right? Dude’s a great musician but a total dick.

For a seventeen year old this was hard to reconcile. Lou Reed’s music is peppered with delicate sensitive pieces that must have required some seriously honest introspection. I’m not saying sensitive introverts can’t be assholes but under normal conditions you wouldn’t expect it. Assholes aren’t usually so self-aware and empathetic to their fellow humans.

And yet as far as I can tell pretty much all rock stars are assholes. Just Google:

{rockstar_name} is a { dick | asshole | prick | other_bodily_part }

and you’ll see.

But heck, that’s OK. They’re rock stars. They make music that makes us feel good. They make tons of money and are surrounded by sycophants whilst being asked inane questions by half-witted journalists. They don’t live under normal conditions. Who could remain in non-asshole territory under that kind of provocation? Highly creative people tend to be highly strung. Greatness doesn’t come for free.

In the world of software development the term rock star is in fairly common use. If you’re a start-up with a tough scaling problem you might deliberately go looking for a coding rock star. In large enterprises it’s seen as a bit of a coup to lure in a rock star.

And the analogy isn’t a terrible one - both are revered to some extent, both wield their magical powers in ways that average people are unable to do, both command higher-than-average fees, both can be assholes when they have to interact with those they don’t respect, and apparently we all want to be one.

Most importantly both are tolerated because we prioritise their product over their behaviour.

And all this would be fine if it were true and not some mass-hallucinatory bullshit. I’ve worked in big companies for twenty-five years, much of which has been in enterprise architecture, so I know me some bullshit when I smell it.

When it comes to music, I admit to owing a collection full of jumped-up jerks with whom I have no desire to meet or converse. Maybe when I was seventeen, but not now. Maturity has furnished me with the pleasantly detached ability to pay artists to listen to their music, and be moved by it, whilst they spend my money on being as twatty and arrogant as they choose. My interaction with these musical dicks is restricted solely to experiencing their art. I am glad they do it. Their work adds a quality to my life that is irreplaceable. Whatever odious personae they wish to develop is their own business.

But no so the software rock stars.

If you’re in the team you can’t experience the product of a software rock star without having to experience them in person.

I’m a reasonably tolerant individual. I think you have to be to work in the software world. Many, if not most of us are socially awkward, insular, given to streaks of odd behaviour, diffident, crabby. That’s not surprising given the intellectual nature of the work. It’s hardly a place where empty-headed fools will prosper. But odd inoffensive behaviour is a far cry from acting like a diva (or divo as is more often the case). So should we take the same attitude to software rock stars and accept that the cherished qualities of their product surpasses any tendency to act like more of a brat than Justin Beiber?

I used to think so. Software teams are notoriously hard to manage what with introverts at one end and egos at the other. Surely the blessing of one or two maestros is worth a little management overhead. But on closer examination I don’t see that the case holds up. The type of people we hire is the most important factor in determining the success of our work.

When we think about what desirable outcomes hiring a rock star developer brings I see four main areas: the product itself, the cohesion of the team producing the product, the wider business that interacts with the team, and finally the wider software community and culture that surrounds both the team and the business.

Rock Stars and Quality Products

Let’s start with the code. If it’s possible to show that software rock stars (unlike their musical namesakes) don’t actually produce a superior product, then the rest of the case will fall like drunken ninepins at jumpstyle dance-off.

I don’t want to get into a protracted discussion about what good code is but most of us know it when we see it. We also know what bad code looks like. The more enlightened software developer knows that pretty much all code can be improved. What tends to happen is we first write code that works and then periodically we (or someone else) tidies it up so that it still does the same job but gets successively easier to read (which implies it better expresses its purpose, maintains changeable aspects in places that makes them easier to change etc.). There’s a point of diminishing returns here too - later refactorings can sometimes only produce minor improvements that don’t make them worth the effort. Past the diminishing returns point though are a whole series of changes that make the code more terse, more dense and therefore less expressive. Or maybe add layers of indirection that could accommodate future change that’s not yet been requested.

So there’s dumb code (too wordy, overly expressive, requiring too much effort to change) then smart code (just expressive enough, change impact in line with change complexity) then too smart code (not wordy enough, hard to decipher, unnecessary indirection). Code that’s too smart is harder to maintain. Code that’s too smart is often the result of a science project conducted by a previous developer. Rock stars don’t start with dumb code and move to smart code. They have to go right to too-smart because, dude, they’re rock stars.

Good code doesn’t come from the place we think it does. It’s not what you know or how clever you are it’s far more about how deeply you care for your successors. It reflects your level of discipline in being able not to overwork it and make it smarter.

As Mark Twain said:

People don’t care how much you know until they know how much you care

I’ve noticed this a lot. Coders (even rock star coders) like code written by people who clearly cared about what happened to the code later. When you clone a repository from github and you can intuitively and easily find your way around it feels kind of warm and fuzzy. It makes you feel comfortable so that even if it breaks you feel more inclined to fix it.

So even without defining what precisely good code is we can say that coders who care about other coders, more than they do about showing off their ‘skillz’, make better code (if we define better code by it readability, expressiveness, responsiveness to change, ability to give warm feelings when forked etc.).

It seems to me that XP practices are specifically designed to promote this kind of philosophy: TDD enable developers to create just enough (dumb) code to meet a functional requirement, CI allows them to come back over and over again to tidy it up (smart) in a safe predictable manner, pairing stimulates open conversations about how clever each solution should be.

Rock Stars and Team Dynamics

Making code too smart has repercussions beyond just the code base it sits in. It goes without saying that rock stars aren’t team players. They couldn’t be. Without having the big ego, being the saviour of the project, hogging the limelight, rock stars wouldn’t be rock stars. They’d be just like everyone else. Code that’s too smart is hard (sometimes deliberately) to share between people. If it were easy to share then there would be no limelight. Code that’s too smart comes from a deeper desire to be indispensable. If a rock star developer could simply show up, fix a problem and leave, they would eventually be forgotten. Being forgotten is unthinkable. Rock stars do leave projects of course but what’s more important to them is the idea that when they do the project must fail. Perversely it’s that failure that will prove just how indispensable they were.

To maintain the pretence that a rock star developer is a rock star, the code must be overly smart because this enables them to dismiss other team members as simply too dumb to understand their greatness. Apparently it’s also OK to put it into production despite the fact that nobody can understand it.

This is the great difference between real rock stars and rock star developers. Any half-decent guitarist can play all the chords to a Lou Reed record. Hardly any could have written them. Which is fine because nobody else except Lou Reed writes Lou Reed songs. There’s no maintenance or changes required - simply listening and playing. I’m pretty sure I could write a track nobody would want to listen to and that might make me many things but it would not make me a rock star.

Rock Stars and the Business

So their code is a nightmare for everyone except themselves and they leave a wake of screaming shit behind them. But what about the organisation that funded all this? I said at the beginning many big companies go out of their way to court rock star developers. Surely there’s a pay off at some higher level.

Unfortunately not. A high-functioning software team in any organisation should be like an acting ensemble - when it’s performing you should not consciously be aware of the performance. It just happens. Bad actors are bad because you can see that they’re acting. Their performances aren’t credible. Software teams are the same. Discussions are had, requirements are generated and a product comes out. Something happens but to the uninformed observer it may as well be magic.

I recently watched the entire boxed set of Breaking Bad. Afterwards I watched some of the extras tracks on the DVDs and was immediately shocked that Brian Cranston isn’t a chemistry teacher and that Aaron Paul isn’t a misguided meth head. I wasn’t the only one apparently - Anthony Hopkins wrote an email to Brian Cranston saying it was the best acting he’d ever seen. I enjoyed the product of their efforts without ever really being conscious of the fact that these are just people who’d learned lines and pretended to be fictional characters.

Perfection is when the experience comes without conscious knowledge of the performance. I enjoyed the insights into how Breaking Bad was made and I appreciate the skills those people brought to bear to pull it off, but my role was right at the end as a blissfully ignorant observer.

The twisted economics of software are that its cheap to produce and insanely expensive to maintain - if we want to look for ways to make it more cost-effective then it follows that most of the effort should go into the latter and less so the former. That is to say we need to allow others to be blissfully ignorant of the creation side, and able to experience only the functionality delivered, unconscious of the mechanics below. Rock stars demanding recognition does not make for an invisible creative process. Code that’s too smart means the business will also be too readily aware of the cost and complexity of the software rather than able to experience its functionality.

Rock Stars and Cultural Impact

Like everyone who reads a lot of blog posts, I’ve noticed the recent upsurge in reported sexism incidents in and around tech conferences over recent months. And like many I’ve thought about writing up my take on things. But, truth be told, I have very little to add to the debate. Clearly our industry over-represents middle-class white males and under-represents everyone else. The most polite thing I can say about it is that it’s a very unhealthy state of affairs. What’s truly worrying is that, as a whole, we do very little to address this cultural aberration.

I’ve read various thoughts on the matter. Should we, for example, positively discriminate for women speakers at conferences over males? Honestly, I don’t know. I see the logic but it does run the risk of being seen as artificial and somewhat patronising. The fact is the software community itself is demographically distorted. Selectively choosing speakers may set some good examples but it will be a long time before that feeds through to the cultural structure itself.

No right-minded person would want to see anything other than speaker profiles reflecting our wider society’s gender, race, sexual orientation, religion, body shape, hair colour or favourite ice cream flavour. Whatever the statistical make-up of the population at large I am not aware of any of these attributes materially impacting an individual’s ability to write good code.

So are we all right-minded? Or do many of us act like assholes sometimes because in our sub-culture it’s tolerated?

In abstract terms, given that good code comes from intelligently applied logical thinking, the software community should be an example to other industries of how to hire well and equally. The relative age of the industry should have meant that old fashioned twentieth century mind-sets never polluted our culture. Unfortunately neither of these are true. But they can be.

Rock star developers exist because we let them. Once bad behaviour is tolerated (or worse, glamorised) it changes what’s “normal” and gives license to any of us to act like an asshole, which gives the impression that more of us are assholes than is the case. You can’t expect a balanced representative industry under these conditions. Nobody wants to join a bunch of assholes who think that some of them are akin to rock stars just because they construct a series of logic instructions for a machine in some arcane manner.

OK, so it’s just a job title and not even one officially used by the recipient. But like my earlier post on evil in corporations it’s symptomatic of our relentless need to outdo and exceed previous (mostly stupid) decisions. We can just have developers, we have to have senior developers, lead developers, principle developers, architects, lead architects, chief architects, chief enterprise architects, it’s part of the:

We get X. We are satisfied with X because relative to our needs X is good. Then we see others with X. Now X is normal. We need Y. Y is bigger or better than X. We are dissatisfied with X and now need Y.

So first off let’s stop using the term. Job titles, even unofficial ones, should be about what you do not what (you think) you are. That includes fucking ninjas too.

An obsession with hierarchy and status are poisonous in software development. Experience may save time by avoiding rookie mistakes but then enthusiasm and attitude create productivity. Jason Fried wrote a short post on hiring the other day entitled “The Person They’ll Become” saying that whilst it’s very nice to find someone perfect in all respects for an open position it’s “not how it usually works”, instead one has to envisage how that person may develop. Yes, experience is useful but development comes from enthusiasm and attitude. If you have to sit next to someone for a couple of years on a project it’s going to get old pretty fast if all they ever talk about is what a fucking awesome ninja rock star they are and how lucky you are to be within their gravitational field.

John Maeda recently spoke about his late colleague Bob Silbey who had a natural ability to be confident without needing to feed his ego. Maeda compares the sort of ego that needs to be sustained by feedback, praise and rockstar-like worship to Kaonashi the spirit that feeds off greed in the 2001 animation Spirited Away. We can all be greedy at times. Yet we all need to cutivate a level of confidence to do our jobs well. It’s when confidence requires a grateful audience that code starts to become self-conciously preening and over-complex.

We overrate awesome code anyway. No software should reach production status without having had numerous eyeballs on it (pair programming, QA approval, product owner demo) because development, like scuba diving, is not a solo effort. When it’s done solo small mistakes can be catastrophic.

And finally let’s stop hiring rock star assholes. Create interview screening questions to weed them out - favour attitude and aptitude over skill, look for likability, generosity, modesty, a wide set of interests outside of work. At the first smell of arrogance or complacency stop the interview and get the next candidate in. Give your company a reputation for a zero-tolerance policy to rock star assholery. You’ll get better, happier, more inclusive teams and set a behavioural benchmark that doesn’t suggest acting like a big baby is OK. And you’ll have better cheaper software in the long run.

Notes

• The subtitle is taken from the third track on Transformer - ‘Perfect Day’ - a gently rising piano and violin piece that stands squarely in the evidence box marked “not written by an asshole”.

• The painting is by A Amarok and is called Playing Guitar. You can buy a copy here.

• Just as I was finishing this post it was announced that Lou Reed had died. My first thought was to go back and use another rock star in my asshole example, except that would be exactly the kind of suck-up fakery I’m talking about. As part of reliving the memories I’ve had Lou Reed on Spotify for a couple of weeks and been struck by just how musically versatile he was. My older and wiser brain now hears things in his work that weren’t obvious to a seventeen year old trying to impress a girlfriend. Such is the singular beauty of that work that it seems unfair not to give him the benefit of the doubt on some of those asshole stories. At the end of the day he was just a guy with a kooky talent.