Recently I’ve run across several uses of the phrase “rockstar developer” or “rockstar programmer” (“code ninja” is another hip variant). The term shows up on slashdot, for example. I’ve also seen it in job postings and in blogs.,, A rockstar hacker archetype is standard fare in TV shows, where his or her computing feats are practically a superpower (Agents of Shield, Person of Interest, Leverage, Scorpion, …) Of course Hollywood loves the notion, too; I thought The Imitation Game was fascinating, but besides taking liberties with history, it portrays Alan Turing in a distorted way that feeds such mystique. (Turing was absolutely brilliant, and certainly one of the most important pioneers in computing. But he didn’t invent his codebreaking machine alone.)
It’s even in my inbox. After I began writing this post, I got an email from a recruiter on LinkedIn, looking for “superstars”:
The buzz about these mythical supercoders has begun to raise my hackles.
Plenty of developers consider themselves gifted, and not infrequently, they are right; I’ve met amazingly smart people in this industry. It’s also true that in software, the standouts are way more productive than their average or under-average peers. If memory serves, Facts and Fallacies of Software Engineering says the best programmers/coders/designers are up to 28x times better than the worst. The actual numbers are debated, and I think it’s possible to get carried away, but I could believe some big ratios.
Nonetheless, the worldview behind the “rockstar” label is naive and dangerous, and I urge you to help me correct it. Here’s why:
- 1. Making a valuable software product is way more than writing clever code.
- Understanding all the people in the value chain of your software, and doing the hard, unrewarding detail work to guarantee that their needs are addressed throughout the full lifecycle of what you build is usually way more important than inventing a new and mind-bending algorithm. Addressing the need of your business to make a profit is usually a good idea, too. Perhaps the vast residual work is what Thomas Edison had in mind when he said,
Genius is one percent inspiration, ninety nine percent perspiration.
- 2. The best developers are superb team members, not prima donnas.
- I don’t care if you’re in a startup and you can only afford to hire one developer–if you think that developer can ignore teamwork, you’re foolish. On day 1, even a one-person dev phenom has to work with those who test or document or support or deploy or sell. And if your startup has staying power, the day will come when Codezilla has to work with a contractor, or an understudy, or a team in Johannesburg or Timbuktu that will take over or integrate with what they’ve built.
- 3. If nobody understands your code, you’ve failed.
- How can there be a version 2.0 if there’s nobody who understands the groundbreaking ideas in 1.0? A big part of creating lasting value is communicating so others can appreciate and build upon your work.
- 4. Nobody knows everything.
- It might be possible to crank out dime-a-dozen websites without research or innovation, but most projects with genuine market value are broad enough that they demand more skills than exist in any one person. Wise developers (as opposed to simply clever ones) are humble and interested in learning.
- 5. Relying on magicians stymies progress.
- When we attribute remarkable results to a murky thing called “genius”, we abdicate the responsibility of other smart people to deliver. This makes good old-fashioned elbow grease seem dull, and shifts all the glamour to pulling a rabbit out of a hat. We all love the dazzle of a great show, but we’re better served by figuring out how to predict, replicate, and optimize success, not treat it as a mystery.
- 6. The best metaphor for the pinnacle of our profession is a jaded, ego-centric, overpaid, dissolute show-off with a limited repertoire? Really?
- (Can you tell I’m not big on rockstars? :-)
To temper my complaining just a wee bit, perhaps it’s worth acknowledging one way that the “rockstar” metaphor does work: I have seen many performances during my career that were worthy of admiration–even applause. Working with people who are humble and smart and generous, who push the limits and raise the bar in all the best ways–that’s an experience as memorable as any rock concert. Definitely worth the price of admission.
Do you agree?
9 thoughts on ““Rockstar Developers” are a dangerous myth”
I can’t agree with your last statement more. I have the same issue with “Guru”. Rather than “Rockstar”, couldn’t we have something that at least incorporates the features of a winning programmer? You know, like “Savant”, “Virtuoso”, or even “Gladiator”? I don’t even really listen to Rock & Roll.
Ooh, I really like “virtuoso.” Gladiator is an interesting one, too. I don’t usually think of what we do as a battle, but now that I think about it, I do talk about having “battlescars”…
Daniel, I’m really glad you wrote this post. I wish more people, especially managers, understood that a prima donna developer really undermines their organization and can torpedo their results. In one group I was in (company name shall remain anonymous) we had three “rock stars” on the same team all ignoring the others and writing redundant code at rapid velocity. They impressed the boss with their short-term results and then quit or changed to another group before the consequences had time to catch up to them. I got to clean up the mess.
Oh, to add to your list: “unicorn developers.” Heaven help us.
Yes, it’s really unfortunate that folks sometimes skip out just when the exacting work of maintaining a newly created codebase (finding and fixing all the subtle bugs, and trying to polish the rough edges) is beginning. What seemed like a good design early on can look pretty dismal when compromises begin to manifest their long-term consequences…
I admire you for being the sort of guy who is in it for the long haul…
Does this mean I should quit referring to you as the best rockstar, guru, code ninja that I know when people ask me “Do you know Daniel Hardman?”?
Hah! Of course you should. You know lots of awesome coders (and you are one yourself). :-) Whenever I do something boneheaded (like when I wrote, recently, about taking forever to diagnose a simple missing mutex), I am reminded of my amazing capacity to not be very smart…