10X, rock stars, and the myth of meritocracy
Rock star. Ninja. Genius. In the world of tech, there’s a longstanding cultural mythos around the software developer who is not merely good but possessed of an Olympic brilliance and productivity. This belief in the unicorn programmer is so well known that the concept has a name: the “10X” coder. As the moniker suggests, it describes a programmer who is provably better, multiple times so, than the average code monkey.
It’s not hard to understand why so many coders love the idea that programming is a world of pure willpower, raw talent, and 10X meritocracy. On the sheer level of everyday coding, it can certainly feel true. One cannot bullshit the computer, or bluster through a failed code test. “You can’t argue with a root shell,” as programmer Meredith L. Patterson wrote in a 2014 essay, adding: “Code is no respecter of persons. Your code makes you great, not the other way around.” Let the noncoders hand wave and plead and persuade; real programmers respect only running code, damnit. As Mark Zuckerberg wrote in an open letter when Facebook went public: “Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: ‘Code wins arguments.’ . . . Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win–not the person who is best at lobbying for an idea or the person who manages the most people.”
As another metric of merit, some coders pointed out to me that programming is a rare form of engineering in which totally self-taught individuals can be accepted by highly credentialed peers. “To me, the most fascinating thing about computer science is that it’s the only STEM field I’m aware of where there’s this combination of people who are super highly accredited working side by side with people that just taught themselves everything,” says Johanna Brewer, who, indeed, taught herself programming beginning in middle school, then earned a PhD in information and computer science and founded several companies.
Tracy Chou, a programmer known for ferociously productive stints at Quora and Pinterest–“an absolute rock star,” as Pinterest cofounder Ben Silbermann once gushed to me–has seen similar dynamics. “I think a lot of the people who have been successful in software have not been the people who would classically be successful in other business pursuits,” she says. “And to be successful there, they want to really own that success.” She also points out that programming’s often-obtuse nature–to noninitiates and sometimes even to other colleagues–makes mystical claims of extreme merit easier to pull off. “There’s something about the fact that code is incomprehensible to most people or hidden from most people,” she adds. “And even when it’s not hidden, it’s most often incomprehensible. And so it’s easier to hide behind a charade of, ‘Oh, it’s meritocratic, and if you understood, you would know.’”
Market competition of merit
The world of open source software–in which code is released online for anyone to examine and tweak–is often particularly seen as a meritocracy, because it’s all about competing to have your (often volunteer) contribution accepted into a project.
Consider the most well-known success story of open source, the operating system GNU/Linux–often referred to simply as Linux. Like Windows or MacOS, it’s an operating system that runs a computer; unlike those, it’s free to use, and anyone can download and inspect its roughly 25 million lines of code. Linux was initially started in 1991 when the Finnish university student Linus Torvalds decided to create his own kernel for an operating system just for fun. It wouldn’t be “big and professional,” as he wrote when he first announced it online. Soon Torvalds had a simple kernel running, and he put the source code online for any other hackers to look at.
Then the snowball began to roll. Pretty soon programmers worldwide were writing him to suggest new features to add to Linux, offering snippets of code, or posting bug fixes. Torvalds adopted the suggestions he liked (he “pulled” in their code, to use the jargon). Linux gradually grew more and more features, all contributed by strangers worldwide. Eventually there were hundreds, and then thousands, of contributors. To make it easier for so many disparate coders to all tinker with a single code base without their changes getting mangled up together, Torvalds wrote “Git,” a piece of software that is now also widely used by coders. Git lets you pull in someone else’s contribution or quickly revert back to an older copy of the code if a new change you’ve made has screwed things up.
As some of its fans argue, open source becomes a sort of market competition of merit–a race to see whose idea can be judged so good that other coders will agree and go, Okay, sure, let’s accept that code into our project. Open source thus can, to many involved, feel like a pure distillation of merit. With Linux, Torvalds became the “benevolent dictator,” accepting only the contributions to the Linux code base that struck him as truly useful and excellent. The barrier to contribution is, in theory anyway, quite low: Just download a copy of the Linux source code, make any changes to it–which will show up in the “tree” structure of the code, if you’re using Git to manage your changes–and then send a request to the core Linux contributors, saying, Hey, check out my contribution. If they like it, it’ll go in, and thus become used by millions of firms worldwide. It’s a little more complicated than that in practice, but this is a microcosm of how most open source projects tend to work.
Superstars gone sour
The reality of a world run by superhero talent gets messy quickly–and can be considerably less productive than it might appear, as Jonathan Solórzano-Hamilton discovered. Solórzano-Hamilton is a software architect who worked with a self-professed rock star programmer. “Rick”–as Solórzano-Hamilton pseudonymously called him, while recounting the story in a blog post–was known throughout the firm for his ability to solve anyone’s problem: Ask him, and he’d sketch out a quick solution on his in-office whiteboard. He was the head architect, designing projects, and also the top programmer, cranking out the code itself. He often stepped in with a lifesaving fix.
It appeared that sense of being indispensable grew on Rick, worked its way into his psyche, and turned sour. He started regarding himself as the coding superstar of the firm, the 10Xer towering over all the mere mortals. Convinced that his skills were crucial to everything, he took over more and more tasks, more and more pieces of code.
But despite Rick’s work, the project was blowing past its deadlines. If a project is big enough, there’s no way a single person can do it all, no matter how talented they might be. The project ran fully one year late, and the managers realized it wasn’t likely to be ready for two more. Rick was monomaniacally trying to be the single hero; worse, it seems his managers indulged his self-mythologizing.
“Rick was churning out code faster than ever. He was working seven-day weeks, 12 hours a day,” Solórzano-Hamilton wrote. “Everyone knew only Rick could pull the team out of this mess. Everyone held their breath and waited for Rick to invent the miracle cure that would mend this crippled project.” Meanwhile, overburdened with work, he was getting grumpier and isolating himself from others.
Solórzano-Hamilton was asked to help and see if the project could be saved. A meeting with Rick did not go well. “You will never be able to understand any of what I’ve created,” he raged. “I am Albert fucking Einstein and you are all monkeys scrabbling in the dirt.”
When Solórzano-Hamilton looked at Rick’s code, though, he realized it was so idiosyncratic and undocumented that nobody else would be able to maintain it. They spoke to Rick and told him they wanted to build a new product from scratch, with everyone collaborating on it. Rick angrily dismissed that, too. As things worsened, Rick wouldn’t take time off, he’d revert code written by others, and belittled colleagues.
Eventually they fired him. And then, behold, things improved: His teammates set about building a new, dramatically simpler product. By the time they were done, the replacement product was less than 20% as big and complex as the previous project. That meant it’d be much easier for new employers to read it, grasp it, and maintain it. They wouldn’t need superheroes. Better yet, the teammates got it done in just over six months. “There were no Ricks left on the team. We didn’t have any mad geniuses building everything from scratch. But our productivity was never higher,” Solórzano-Hamilton wrote.
The company had run smack into the noxious downside of the worship of coder merit: It can create “brilliant jerks,” a caste of programmers who come to believe the myth of their own irreplaceability. You wind up with aggro blustering types who not only drive other talented folks away but often wind up producing work that—ironically— isn’t even very useful, because it’s so locked up inside their own heads. Sure, their talent might be quite real, but who cares about that when their cult of personality wrecks the enterprise?
Divas and dysfunction
Quite a few coders I spoke to had horror stories of working alongside talented but entitled assholes. One Y Combinator firm hired a Russian coder whose work was superb, but who’d snark, “I hate it here” if you asked him how things were going. Why do you hate it? “Because everyone’s work is shit,” he’d reply. “He was a total diva,” the head of programming said with a sigh. As Bonnie Eisenman, a programmer for Twitter who’s an expert in React–a code library increasingly used to make apps–puts it, “The whole myth of the rock star coder creates dysfunction.”
Brilliant jerks aren’t even necessarily worth it, because while they might be useful for solving a hard, short-term problem, the wreckage they cause to morale can be hard to repair. Other talented employees flee, unwilling to wrangle with the jerk. “I’ve met people who are the most brilliant programmers, but they make things that never see the light of day because nobody else can work with these people,” Grady Booch, a veteran IBM coder, tells me.
Even when the 10Xers like Rick are productive, writing that much software–that quickly–tends to produce what’s known, in a lovely phrase, as “technical debt”: a bunch of wreckage produced by moving too quickly. A fast-cranking coder will almost always use shortcuts and employ patched-together solutions that will require, in the years to come, careful and patient cleanup by later colleagues. “The 10X engineer is not actually 10 times more productive than everybody else,” says my friend the developer Max Whitney. “A 10X engineer is out there–I’m quoting somebody off the internet–generating 10 times more work for everyone. So, they’re like the tip of the iceberg, making something flashy and beautiful, and leaving so much technical debt everywhere.”
Part of the reason coders love building startups, as Andreessen notes, is they get to move quickly. But even here, the early heroes can create messy code bases that only function well enough to acquire early users, and soon need cleanup by more patient programmers who bring order to the chaos.
When Tracy Chou was hired at Pinterest, she headed up a heavy rewriting of its backend. While poking around in the code base, she discovered something weird: Whenever a user searched for a term, the server would run the query twice. What’s up with that? she wondered. Chou eventually discovered that the code for making a query had been accidentally cut and pasted twice. Someone in the early days of Pinterest, it seems, had been working too quickly. By cutting that single mistaken line of code, Chou doubled the efficiency of Pinterest search. Oftentimes, the real 10Xing isn’t in writing the code, but rather in fixing someone else’s blunders.
Adapted from Coders: The Making of a New Tribe and the Remaking of the World by Clive Thompson, published by Penguin Press, an imprint of Penguin Publishing Group, a division of Penguin Random House LLC. Copyright © 2019 by Clive Thompson.
(9)
