In search of the 10x developer

At LeadingAgile recently, we’ve been talking about the idea of the 10x developer. Is there such a thing? If so, how can you tell? What does it even mean, exactly? And where are they all hiding?

Is there such a thing?

I don’t want to spend a lot of time on this question. If you “believe in” studies, then you can easily find studies that support the idea. If you don’t, you can easily find software developers whom you respect who can tell stories about colleagues who demonstrated extraordinary ability. Let’s accept, for the sake of discussion, it’s true that some individuals are able to deliver on software-related work far more effectively than average.

Even so, should companies be shopping for individual 10x developers? Avichal Garg (several years ago) wrote, “The “Economics of Superstars observes that in some industries, marginally more talented people/groups generate exponentially more value.” He further observes that in the software industry, “the superstar is the team, not the individual.”

The Agile community, in particular, emphasizes the formation of cross-functional teams that stay together long enough to become “gelled” so that they function as a “true team,” as opposed to a “work group.” Garg notes that startups tend to look for individual superstars, while larger companies tend to recruit for individuals who possess specific technical skills. Typically, neither type of organization explicitly recruits to build superstar teams. There is an important implication here for assessing individual developers: An individual may appear to function at 10x while a member of a high-performing team, and then not function that way in a different environment. If we want to identify individual 10x developers, we have to be aware of this possibility and take it into consideration. Many of the “studies” on this subject look strictly at individual performance, with no team context. They may be overlooking something.

How can you tell?

This is a tricky question. Some of the “studies” have used measures like “years of experience” or “lines of code produced per day.” A colleague, Scott Sehlhorst, observed, “What’s funny for me is I always talk about easy to measure vs. important to measure. I need to add important to measure, but we don’t know how, so we use easy to measure data and mislabel it to my soundbite.” It’s pretty easy to measure years of experience and lines of code, but do such measures tell us anything about how “good” a developer is? What measures should we consider?

Salvatore Sanfilippo, writing on his blog antirez.com, points out that it’s hard to quantify what makes a 10x developer because software development is a non-linear activity, fundamentally unlike activities that are easy to measure. He suggests the various skills that go into software engineering complement one another in a multiplicative way. This quality of software engineering makes it especially difficult to rank developers as “better” or “worse.”

And yet, we all seem to have pretty strong opinions about which developers are “better” or “worse.” If we can’t quantify it, then how do we reach our conclusions? Yevgenij Brikman writes, “Even if you ignore the studies […] and declare that ‘programming productivity’ is hard to measure which it is we can still have a discussion about 10x programmers. Just because something is hard to measure doesn’t mean we can’t reason about it.”

Most teams have one or two members who function as technical leaders, whether or not they have an official title to that effect. They’re the ones who can usually help when you get stuck. They’re the ones who remember details about edge behaviors of APIs and libraries. They’re the ones who seem able to breeze through debugging or crafting unit test cases. They’re the ones who routinely refactor as they go, without having to be reminded. They’re the ones pulling their third or fourth card while others are still struggling to complete their first work item in the current development cycle. Maybe, on your team, it’s you. And even in the absence of quantitative measures, you know exactly who they are, without question. How do you know?

I don’t think the answer is to look at “productivity.” You already know my opinion about that. If we look at productivity, we’re going to have the problem Brian Craft mentioned in a comment on Salvatore’s blog: “There’s another, more common way to be a 10x programmer: generate technical debt at a rate that requires ten other developers to clean up the mess. The real magic is that this feeds back on itself: you look more productive while producing garbage, and everyone else is less productive, because they’re bogged down in your disaster. Management then directs more resources to you, and less to everyone else, since you’re a ’10x programmer’ who is ‘getting things done’.”

You don’t have to read very deeply between the lines to guess what sort of organization Brian must have been working in when he made that observation. Most of us have been there, too. The definition of “productivity” is just “output over input.” There’s no consideration of “value” or “quality” or anything other than quantity, if you just look at the basic English word. So, productivity can’t be the measure of interest to identify 10x developers. Personally, I prefer the notion of effectiveness.

To me, effectiveness implies more than just delivering the customer-defined business value of the work items in our backlog. It also implies satisfying the needs of all the stakeholders of our code. That includes fellow team members, future maintenance programmers, and everyone else who has a stake in the quality of the code. With that in mind, I’ll observe one of the distinguishing characteristics of the 10x developer is awareness of the big picture; the natural tendency to act locally and think globally. Even when carrying out a small task, like modifying the build script or renaming a variable, the 10x developer thinks about the impact on all stakeholders. This is one of the reasons no one has to come around later and “fix” what he/she has done, as Brian mentions in his comment.

What makes a 10x developer?

Here’s an assertion: To become a 10x developer requires talent, practice, and guidance. If any one of those factors is absent, you won’t get there.

Those who don’t believe in the concept of the 10x developer might say that excellence is already within you. Your task, should you choose to accept it, is to discover the 10x developer within. I can agree that if you never look for that inner 10x developer, you won’t find him or her. That’s nothing more than a specific case of the general rule, “You only find what you look for.” But seeking doesn’t guarantee finding.

I’ve worked with and observed a lot of developers over the years. On the whole I’d say they follow the conventional bell curve. Most of those who are able to hold jobs in the field are at least pretty good coders, even if there isn’t much more to say about them. There are some who are really in the wrong field and should consider a change. And there are some who just seem to take to programming naturally, like breathing. There is such a thing as talent.

Talent without practice won’t lead anywhere. Most developers I’ve met never practice. They only apply their skills to the actual work items they need to complete for projects at work. The first time they have to use, for instance, recursion on the job is literally the first time they’ve ever used recursion. The first time they have to refactor, say, a massive switch statement toward the State pattern at work is literally the first time they’ve tried to do it. Is it any wonder every piece of work takes them longer to complete than their 10x colleagues? The first time the 10x person did it (for some definition of “it”) you can bet the solution didn’t flow lightly from their fingertips. They had to learn how to do it.

One difference, then, may be that the 10x developer shows up for work prepared to do the job. There’s an old saying that 90% of success is just showing up. Maybe that isn’t quite enough. Maybe what you bring with you matters, too.

The developer’s people recognize as stronger are the ones who invest some of their own precious time in honing their skills. They work on side projects on their own time, they contribute to Open Source products, they participate in code dojos and hackathons and similar events. They don’t lean on their natural talent to slide through the day, even if that would be sufficient to out-shine their less-talented colleagues. I’ve seen plenty of those, too; people would could be 10x developers, but don’t care.

Jessica Kerr, who has a well-deserved reputation as one of those mythical 10x developers, isn’t quite a believer. She writes, “When do we get that exhilarating feeling of hyper-productivity, when new features flow out of our fingertips? It happens when we know our tools like the back of our hands, and more crucially, when we know the systems we are changing. Know them intimately…” and so on in the same vein. Her take is that a person will seem to be 10x more effective than average if he/she is working on familiar code using familiar tools in a familiar environment.

She’s undoubtedly right. I get the same sort of feeling myself when I’ve become deeply familiar with a system. Back in the 1980s, when I specialized in CICS, I experienced that feeling. Initially, CICS felt like a huge mass of intolerant, frustrating little idiosyncrasies controlled by a bewildering mass of special keywords. If I touched it at all, it broke. Eventually, I turned a corner. I even remember the sensation when it happened. From that point forward, CICS felt like an organic entity that had a personality I understood. When it misbehaved, I was pretty good at going straight to the component where the problem lay. I could touch it without breaking it. It even seemed as if I could make it do anything I wanted, safely. Ah, good times.

Since then, I’ve become familiar with a few other systems, and it’s always the same feeling. It’s exactly as Jessica describes. But is that what people mean when they say 10x developer? I don’t think so.

I think people are talking about developers who are generally 10x. Even so, I think Jessica touches on an important point. One factor involved in building expertise is practice. When you know a system well, it’s because you’ve spent a fair amount of time working with it. I learned CICS very well by making every conceivable mistake, and crawling filthily out of one self-dug grave after another in the middle of the night. So, it might be relevant to ask, Can you practice development skills generally, as well as in the context of a particular system?

I think you can, and this brings us to the third factor: guidance. Natural talent and the desire to shape it through practice are necessary, but not sufficient. It’s very helpful to know what to practice and how. You may or may not stumble into these things by trial and error, if you spend enough time practicing on your own. In view of the number of things to learn and the pace of change in the field, do you really have that kind of time?

Fortunately, there is guidance available. A lot of it. There are right ways and wrong ways to do everything. There are things you can safely ignore and things you’d best pay attention to. And there are ways to practice development skills mindfully, with specific learning objectives in mind. If you have the talent, and you are willing to invest the time in practice, then you need to find appropriate guidance.

In some cases, all you need is an online tutorial you can work through at your own pace. In other cases, you may need to sit down with a knowledgeable colleague and have them step you through some new skills. I might observe a key difference between the average developer and the 10x developer is that the average developer waits until the boss signs them up for a training class, while the 10x developer goes out and learns things because he/she actively keeps up with advances in the field. The boss wouldn’t be able to stop them from learning.

Conclusion?

I’m not sure all this verbal meandering has led to a conclusion. I still feel as if the 10x developer is a bit like art: I can’t define it, but I know it when I see it.