10x Developers exist, but that’s not the point. Let me explain …
I’ve had some of these thoughts drafted out for a while now. The volume of recent tweets asking Twitter to “stop talking about 10x developers” has increased to the point that I thought I should publish. And I don’t mean for this post to be trollish. Really.
I think that there is value in understanding how expertise and influence are distributed because emotions can flare when dreaded “10 Xer” conversation comes up. Sometimes you’re the expert. Sometimes you’re working with her. Sometimes he’s totally NOT the expert, but everyone else says he is.
Diversity is part and parcel of humanity. We’re different from each other. Full stop. But another part of human nature is to compare ourselves with one another. When this comparison reveals differences in skill, the results can leave the comparator feeling a complex mix of threatened, inspired, arrogant, and inadequate.
Experts lift the veil of authority
Setting aside the specific value of “10x,” it goes without saying that experts are a thing. They exist.
Lebron James is better than me at basketball. I could never have beaten Bobby Fischer at chess. I can play guitar, but not quite as well as Jimi Hendrix. That being said, as the world’s OKest developer, I would bet anyone ten bucks that I could code circles around any of those guys.
So who’s the expert? If Hendrix made statements about software development, he would have had the world’s attention, but not a lot of credibility on the topic. However, if Bobby Fischer voiced opinions on software, he would have gotten both the air time and a lot of interested listeners, even though, to my knowledge, he was never a developer.
Daniel J. Levitin in his book A Field Guide to Lies highlights the difference between experts working within their field of expertise and experts who are just sharing their own opinions.
“Experts talk in two different ways, and it is vital that you know how to tell these apart. In the first way, they review facts and evidence, synthesizing them and forming a conclusion based on the evidence. Along the way, they share with you what the evidence is, why it’s relevant, and how it helped them to form their conclusion. This is the way science is supposed to be, the way court trials proceed, and the way the best business decisions, medical diagnoses, and military strategies are made.” — Daniel J. Levitin
Let’s call this the “Genuine Expert.” This is the developer who has spent years building and maintaining enterprise-scale distributed systems. They understand the failure modes and matching risk mitigation strategies from years of working in the trenches. While they may or may not have a degree from a prestigious university, they can clearly and confidently explain what they know and why it’s correct.
While this developer knows a lot about their field of expertise, they are also very open to new data that challenges their current assumptions. It’s hard to pull the wool over their eyes with new trendy stuff, but they are the first to admit flaws in their current position if that’s what the data shows.
This is in contrast to what I’ll call the “Fraudulent Expert:”
“The second way experts talk is to just share their opinions. They are human. Like the rest of us, they can be given to stories, to spinning loose threads of the own introspections, what-ifs, and untested ideas. There’s nothing wrong with this — some good, testable ideas from from this sort of associative thinking — but it should not be confused with a logical, evidence-based argument. Books and articles for popular audiences by pundits and scientists often contain this kind of rampant speculation, and we but them because we are impressed by the writer’s expertise and rhetorical talent. But properly done, the writer should also lift the veil of authority, let you look behind the curtain, and see at least some of the evidence for yourself.” — Daniel J. Levitin
Any technical leader within an organization should have a sufficient level of charisma and approachability such that they can appropriately influence the direction of their team; however, they if they exert opinions without “lifting the veil of authority,” their expertise is fraudulent.
A genuine microservices expert will defer to the expertise of a more junior frontend developer. An expert full-stack engineer will defer to the expertise of a highly specialized database administrator.
The Equal Voice Fallacy
In an ironic twist of fate, we have created our own problem. We have built the internet and the internet is the Great Equalizer.
Anyone can get an avatar and a screen name. There is no central regulatory authority when it comes to who can post what. You could argue that anonymity is valued more than veracity. This leads to what I’ll call the Equal Voice Fallacy which is the appearance that all contributors to a social platform are equal with respect to knowledge, authority, and validity.
But giving everyone the right to speak does not ensure that everyone who exercises that right will do so with equal accuracy because they come to the table with unequal authority. Social platforms are a fantastic place to observe this phenomenon. A 16-year-old kid with a freshly minted drivers license is likely going to know much less about car repair than a professional mechanic. However, in the comments on a YouTube video, each is represented by only a name and an avatar.
Some platforms combat this by implementing features that track how users engage with other users’ content in order to establish who the experts are. StackOverflow, the internet’s number one question and answer site for programmers, is an outstanding example of this. The community can “upvote” or “downvote” questions and answers and askers of questions are able to mark one of the answers as the “best answer.” Through a complex and ever-improving algorithm, StackOverflow is able to identify experts and even goes as far as to grant various admin privileges to users as they establish authority on the platform.
But even with intentionally gamified platforms, the social noise has trained us to ignore the experts who consistently achieve long term success. There is no system for retracting harmful trends. We just cover them up with new content on the front page of hacker news.
An expert isn’t someone who implements the latest hotness from Twitter while the rest of the team unravels the disaster from last month’s fad-fueled coding binge. If you see an article on HackerNoon about new methodologies for continuous integration, how does that author stack up against Jez Humble? He didn’t just do things by the book, he wrote the book. Literally. It’s called Continuous Integration and it’s fantastic.
Fundamentally, it’s important to know how to identify experts in all the noise without falling into the trap of the equal voice fallacy.
The cult of ignorance
Now, it is easy to sit back, point to social platforms, and chuckle at the trolls, but be aware of the ease with which the Equal Voice Fallacy can creep into the workplace.
(Photo by Patrick Tomasso on Unsplash)
We use terms like “teamwork,” “democracy,” and “synergy” to mask how we dilute the voice of team members with the most expertise. Isaac Asimov went as far to call this a “cult of ignorance.”
“There is a cult of ignorance in the United States, and there always has been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that ‘my ignorance is just as good as your knowledge.’” — Isaac Asimov
Everyone in an organization is bound to have different areas and levels of expertise. This is a result of the naturally diverse interests, cultures, and career choices that we all bring to the workplace. This diversity is crucial. Just like a multicellular organism is composed of various tissues that perform various functions, a multi-person organization is composed of various people who excel at various tasks.
A liver abandoned on the sidewalk isn’t exactly a viable organism. But equally non-viable is a human body complete with a brain but missing a liver. The nervous system contains specialized tissue for receiving, transmitting, and processing data throughout the body. Together, the neurons in the brain form an amazingly complex yet efficient computational powerhouse; however, the most capable neuron is useless when tasked to metabolize fats for energy, a trivial task for even the most junior liver cell.
In a similar way, members of the most diverse team, while equal as humans, are incongruent with respect to capability and expertise. A mid-level developer is guaranteed to understand debugging code far more expertly than a CFO with decades of accounting experience. (This assumes, of course, that the CFO doesn’t have professional programming experience.) Similarly, a Principal Software Engineer who has been through the meat grinder of web development will not have the financial instincts innate to an average mid-level accountant. (This again assumes that the engineer didn’t pursue a degree in accounting.)
But diversity extends beyond the just areas of expertise. Various members of the same team who perform more or less the same function are bound to vary with respect to their level of expertise. But, achieving a high level of expertise in software development does not happen overnight. Those who naively look on from the sidelines mistakenly see an oversimplified process of 1) write a killer app, and 2) rake in the cash. But the reality is that just the problems encountered in software development, let alone the solutions, can take the better part of a decade to fully comprehend.
Consider this excerpt from an article in Scientific American from 1973 by Herbert Simon and William Chase:
“There are no instant experts in chess — certainly no instant masters or grandmasters. There appears not to be on record any case (including Bobby Fischer) where a person reached grandmaster level with less than about a decade’s intense preoccupation with the game.” — Herbert Simon and William Chase, Scientific American
Scott Kaufman, author of Ungifted: Intelligence Redefined, cites this principle when stating that chess has a “vocabulary” just like a natural language.
“[Herbert Simon and William Chase] argue that these hours are comparable to the amount of time people have spent reading by the time they become adults. Just as adults have a reading vocabulary of about 50,000 words, chess masters have a “chess vocabulary” of about 50,000 patterns stored in memory, with grandmasters having an even larger vocabulary.” — Scott Kaufman, Ungifted: Intelligence Redefined
Malcolm Gladwell continues this line of thinking in his book Outliers and describes how even with innate talent, ten thousand hours of dedicated practice are needed to achieve “true expertise.”
“In fact, researchers have settled on what they believe is the magic number for true expertise: ten thousand hours.” — Malcolm Gladwell, Outliers: The Story of Success
Expertise in software engineering is no different. There are established software and architectural design patterns when building systems. There are integration and delivery patterns when deploying systems. And there are common failure modes and mitigation strategies when maintaining and debugging systems. It is the years of absorbing these patterns that allow expert engineers to instinctually apply solutions while junior developers struggle even to understand the problems.
Now, everyone is going to learn at a different rate, and everyone is going to have a different level of innate talent, but regardless of your intelligence or level of expertise in an orthogonal field, if you want to be an “outlier” with respect to developing software, there are no shortcuts — you have to put in your ten thousand hours just like the rest of us.
This means that if you have not done time in the trenches and software engineering seems trivial, then you are still blissfully unaware of how much you don’t know. This also means that in a meeting if you say something like “How can ______ be so hard? Can’t you just ______?” and the software experts in the room look at each other, hide their smiles, and say nothing, then the ignorance lies on your side of the table, not theirs.
Now back to the quote from Asimov. The collective ignorance of non-software employees and more junior developers is not just as good as the knowledge of an expert Software Engineer. Thus a responsible software decision-making process never gives the ignorance of the CEO and the knowledge of the engineering expert the same weight. (Please understand this is not saying that developers have taken over the software asylum. A developer is never going to out-rank an executive and the decision made by the CEO is always going to trump those of the software team.)
Experts can be invisible to amateurs
I enjoy cycling. It’s a good workout, it’s orthogonal to engineering, and it gets me outside. I’m also super competitive. While I generally ride solo, I take a calculated approach to training and regularly work on various things to improve so that I can beat my own personal bests.
(Not actually me :( Photo by MAX LIBERTINE on Unsplash)
Now, I’m no professional cyclist, but I know what I’m doing. As an extension of that, it’s easy to identify others’ level of expertise. Even if you put an amateur on a $5000 carbon frame, there is the 40 rpm cadence, the elbows-out posture, and the subtle bouncing and bobbing that betrays their lack of experience.
But this is really only evident to other experts. Other n00bs will see a “professional biker” with a “fast bike” and those “clicky shoes” so they must be good, right?
This is really true in any sport. As a totally-not-a-soccer-player, I could look out at a soccer game with a random distribution of player skill and see that certain players seem to be doing well, but I couldn’t tell you why. However, an expert would be able to instantly identify the other experts by identifying certain tells that are invisible to me.
Why?
This goes back to pattern recognition. My time spent riding has not only improved my physical strength and endurance but also my mental capacity to understand the patterns that improve my performance. An extension of understanding these patterns is also seeing them manifesting themselves in those around me.
This is also true with software developers. As a former junior developer, I remember observing, often with frustration, the ease with which some people around me got a ridiculous amount of work done with seeming no effort. Was it a position of privilege? That’s not fair. Was it inherent talent that I didn’t have myself? That’s also not fair.
Thus the rejection of the concept of “10x Developers” likely comes from those who haven’t yet attained a certain level of pattern recognition. Thus, admitting that these “rock star ninjas” actually exist seems to suggest the conclusion that there is a level of awesomeness that can never be attained by the observer. While the conclusion is indeed wrong, the observer is blind to the reason why.
It would be more surprising if 10x developers did NOT exist
Let’s talk for a moment about something called Zipf’s Law.
(Photo by Jelleke Vanooteghem on Unsplash)
The linguist George Kingsley Zipf observed that given a large sample of words used, the frequency of any word is inversely proportional to its rank in the frequency table. This observation is known as Zipf’s Law.
(Zipf’s Law)
In the era of Big Data, we can now do pretty cool things with natural language statistics, such as plot the frequencies of words from a corpus of English text on a double log scale. The interesting thing is that for each corpus, the actual order of word frequencies may vary; however, the distribution always looks like the following:
(Word distribution (double log scale) of the English Language. Source: https://www.ling.upenn.edu/~ycharles/sign708.pdf)
Modern science doesn’t really have an answer for why natural languages exhibit the following pattern. But it gets weirder. A LOT of datasets exhibit the pattern. I first learned about this principle from a fantastic Vsauce video. The host, Michael Stevens, runs through a list of many many completely unrelated datasets that are “Zipffy.”
“Moreover, Zipf’s Law doesn’t just mysteriously describe word use. It’s also found in city populations, solar flare intensities, protein sequences and immune receptors, the amount of traffic websites get, earthquake magnitudes, the number of times academic papers are cited, last names, the firing patterns of neural networks, ingredients used in cookbooks, the number of phone calls people receive, the diameter of moon craters, the number of people that die in wars, the popularity of opening chess moves, and even the rate at which we forget.” — Michael Stevens, Vsauce
This mathematical law is the basis for the Pareto Principle, also called the 80/20 rule. Vilfredo Pareto observed that 80% of Italy is owned by 20% of the population. Microsoft found that 80% of all errors are caused by 20% of the bugs. Additionally, in software, 80% of the functionality will be built within the first 20% of the project schedule. In any “zipffy” dataset, the first 20% of the data contains 80% of the total value.
With a large enough sample size, you will also find that 20% of your developers produce 80% of your commits. Only 20% of the commits will produce 80% of the business value within an application. (Another 20% of your developers will also consume 20% of the coffee.)
Being able to quantify “development effort” is inherently difficult. If you measure commits authored, then developers break large commits into small ones. If you measure based on tickets completed, then they break them into the smallest possible subtask. But if someone told me that 20% of the development team contributed 80% of the effort (even if they couldn’t quantify the results), that claim would at least pass the smell test.
(As a side note, one might ask: “Why not just fire the 80%?” The answer is that even if you did, 20% of those that remain would still produce 80% of the business value, and you would still be in the same situation. That’s just how a Pareto distribution works.)
So given a Pareto distribution with a sample size of 1000 developers, how many developers would you expect to produce 10 times the average? You can ignore all of the “top ten traits of a 10 Xer” articles you may have read. In a group of 1000 developers, you can only expect about 13 (1.3%) of them to be “10x Developers.”
But if you have a group of 3 devs at a small startup, statistically speaking no one is going to be producing 10x the output of the other two developers. You may see a “10 Xer” once you have 100 or so engineers in the building.
How to live in a world with 10x Developers
Some (but not all) 10 Xers are arrogant jerks. Some (but not all) arrogant jerks are 10x Developers.
First of all, the quantity of output doesn’t ascribe worth to the individual. A person is not valuable because of the sheer volume of software they create. If you’re not a “10 Xer” yet, that’s OK. Keep learning. Keep observing patterns.
Secondly, real leadership is about empowering others, not about being the smartest person in the room. Thus, the person who has the biggest impact within the organization is not necessarily the person who personally gets the most done.
“Leaders become great not because of their power but because of their ability to empower others.” — John C. Maxwell
Lastly, don’t make it your goal to get into the top 1.3%. In another article, I describe the fallacy of thinking that software development is a Zero-Sum Game. It’s not. Experts exist, and it’s admirable to continuously pursue expertise, but here is nothing to be gained by ensuring that you are the smartest person in the room. Stated differently don’t try to be a “10 Xer,” but if you find yourself in that position, understand your responsibility to those around you.
As a software developer, zero-sum thinking makes people hesitant to mentor junior developers, contribute to open source projects, champion other people’s ideas, or engage in any other activity that would aid in the success of someone else. Passionately investing in others is a great way to suppress your own ego. Be a resource for others. Market your peers’ ideas. Publically recognize your team’s success. Fight for the underdog. Make yourself vulnerable by depending on the success of your peers.