Speed Alone Doesn’t Define a 10x Developer

There are periods in any project where problems have been described, priorities have been identified, and tasks have been divvied up. It’s time for everyone to put their head down and simply get to work. Across all disciplines, having individuals who are competent and capable of owning and delivering on their tasks is vital to success.

For software developers, this is no different. All software projects need individuals to get tasks done. However, there is a bit of a misconception that an individual who rapidly completes those tasks is “a 10x developer.”

However, simply monitoring the pace of code creation disregards significant responsibilities of developers. Truly great developers also gather and disseminate information and context, identify and correct for troublesome paths ahead, and ensure that their team builds the right software for the problem at hand.  So, let’s cover how that perception is misplaced and how to identify and cultivate those individuals which enable true 10x development.

The Problem With Oversimplifying Measurements of a Developer

There are numerous ways in which organizations and managers quantify the performance and efficiency of all of their employees, software developers included. Common metrics for programmers are often some combination of lines of code created per week, features added per quarter, or – if you’re “agile” – perhaps it’s points completed per sprint. These tend to be a loose measurement that boils down to tracking the amount of new source code created over a given period of time.

It’s easy to understand how these types of quantifications came to be widely used. They’re simple to gather, easy to understand, and most importantly: they’re easily comparable.

The thought is: Coders create code. So if factory workers can be measured in hourly production rates, then so too can software developers.

The top performers by these metrics are often referred to as “10x developers.” Their performance – here being the amount of code created – is about ten times that of their peers. Or more bluntly, they’re seen as being ten times better at their job and/or more valuable than others.

Hollywood movies pile onto this with a very stereotypical trope of the lone hacker banging away on their keyboard. They single-handedly take down large corporations that employ hundreds or thousands of less talented developers. That hacker is doing alone what no one else had previously even imagined was possible. They conceive of it quickly, finish it in minutes, and execute it flawlessly on the first and only try. They’re amazing.

It’s natural to feel that I want that person on my team. However, that is exactly the individual you shouldn’t want and moreover would do well to actively dissuade from joining your team.

These are the wrong measurements and they encourage the wrong outcomes.

Measuring Code Isn’t Just Bad, It’s Dangerous

Measuring and comparing software developers by lines of code created is not only wrong for the purpose of identifying high-value or high-contribution individuals, it’s dangerous. Once developers understand that their value as an employee – and therefore their pay – is tied directly to the amount of code they produce, then they’re falsely incentivized to create more code more quickly.

This is where Goodhart’s Law steps in: “When a measure becomes a target, it ceases to be a good measure.”

Creating more code doesn’t necessarily equate to creating more useful code, or even creating the right code. Creating more code could be as benign as adding additional carriage returns and whitespace. Or, it may encourage the creation of extraneous or overly verbose components. Both of these activities pad the measured numbers without generating positive results.

More detrimentally, it disincentivizes refactoring, simplifying, or otherwise cleaning up the application. These clean up efforts often result in an overall deletion of code. While these efforts contribute significant positive impacts to the project, they ultimately count against a developer’s code output metrics.

More code brings more complexity. New feature development becomes more difficult simply because there are more areas to consider. So, the software requires more attention, maintenance, and fixes just to maintain the status quo.

Every issue and feature takes more time to reason about and even longer to implement. The pace of development comes to a crashing halt. This lag leads to a desire to grow the team and hire yet more developers into the project, all because of an artificially created complexity stemming from a faulty incentive.

Valuing and comparing a software developer solely by their throughput is wrong. It’s bad for the individual, it encourages a less efficient team, and it’s often deadly for the project they’re working on.

Simply put: Quantity isn’t quality. While an ability to execute on a list of tasks is undeniably important, it isn’t what creates strong teams nor successful outcomes. While it’s a valuable trait, it doesn’t solely identify a 10x developer.

Communication is the Mark of a Great Developer

There are an infinite number of ways to solve any problem. A great software developer strives to strike a balance of identifying the most efficient and effective way to reach a goal while simultaneously taking into account the multitude of constraints surrounding it.

Asking Questions without Questioning

Finding that balance takes a broad understanding of the project and the world around it. This necessitates clear and regular communication. There is a nuance here, though: Developers who “ask too many questions” are quickly perceived as being pessimistic or even hostile. Yet, it’s exactly these questions and the experience behind them that are truly valuable and guide the task toward success.

Complex and sometimes difficult conversations build a common, robust understanding between everyone involved. They ensure that all see the same picture and are heading down the same path. This communication should be encouraged and cultivated, not seen as a waste or an annoyance. Still, one must display some tact when navigating these hostile waters.

Keeping an Eye Out for Danger

By maintaining a broad view of the forest through the trees, great developers have the context and foresight to recognize traps and pitfalls before they become a surprise. This is often described as an ability to identify and mitigate risks.

Long before danger is imminent, they ask questions, present alternatives, and shift directions to avoid oncoming icebergs. What once would have been a shockingly costly problem is instead entirely avoided and calmly passed by, unnoticed.

Clearing a Path for Others

Truly great developers don’t just make their own jobs easier. Because they have the broad project scope in mind, they recognize small conflicts and dependencies within and between their own tasks and others’.

Once spotted, they’ll gather information and alternatives. This allows others to continue to focus on the tasks which they’ve been assigned, but now unhindered and well-armed with all of the information and tools required to successfully complete their jobs.

Valuing Clarity

Finally, these developers seek and value clarity and simplicity. This includes not only striving for a clear understanding of the problem, but also an innate desire to always leave software better than they found it. 

These individuals tend to clean up behind others. They feel compelled to refactor and simplify complicated operations. They’re always looking for ways to make the software easier to understand, modify, and maintain.

A 10x Developer is a Complex Package

Heads down hard workers are certainly valuable. Give them a list of chores and they get it done. But it’s not just an ability to check off lists or rapidly create code that makes a 10x developer.

Acting as software sherpas, the true 10x developers are found asking the right questions, avoiding the disastrous problems, and guiding everyone involved through each phase of development following safe, efficient, and effective paths.

Software development shouldn’t feel like a rush from fire to fire. There shouldn’t be a queasiness in your gut when a new email arrives. There should be no screaming or fear of losing a career or business. Rather, it should be calm, clear, orderly, and I daresay: a largely uneventful endeavour where you can look back at the end and marvel at how far you’ve come.

It’s these developers that steadily drive projects forward who are the unsung heroes. They’re the force multipliers of any great team. They’re the true “10x developers,” and should be admired.