Skip to main content

Secrets of the 10x Developer

This isn't a post about whether a 10x developer exists or not -- as you may have already guessed, this post's stance is there is such a thing as a 10x developer.

  • For why the debate over its existence rages, see this post.
  • For why great leadership skills have nothing to do with being a 10x developer, see this post.
If you're still reading, you believe! That's a good thing, because it gives you hope that you'll at last get to the bottom of what constitutes a 10x developer.

There'll be a quiz question at the end, so pay attention! Let's get started with a review.

In Review

First, recall the definition of a 10x developer:
A '10x developer' is one that can take software from concept to production-ready in an order of magnitude less time than a peer of matching experience utilizing the same technologies and delivering the same functionality.
Cast any other descriptions out of your mind. It isn't that your preconceptions are wrong -- what you think of as a 10x developer may diverge slightly -- but in order to gauge what it takes to be one, we're going to have to agree on a definition. Hence, the one above stands. It is not about amateur hour vs. expertise elitism - it is about measurable proficiency.

When you read through each answer, perform this exercise: ask yourself how both an amateur and an expert developer might get caught up...and how a 10x developer skates past both.

Typist

This should be common sense, yet is often overlooked in 10x developer rants: people that know how to type properly are going to be faster that people who don't. And yes, it is a sad fact to have to admit, but there are a lot of programmers that do not know how to type (and an equal amount that don't feel they have to learn).

A typist always beats a non-typist. This is a no-brainer, and a non-negotiable. If you don't know how: learn.

Problem / Solution Fit

10x developers have the ability to examine a problem and see where previously applied solutions would do well. There is a lot of time and energy wasted in building solutions from the ground up (and programmers especially love to build their own stuff vs. work with/maintain other people's stuff). 10x developers have markedly shorter turnaround times because they aren't constantly reinventing the wheel.

FizzBuzz Comprehension

Jeff and Joel famously claimed that the single best way to interview a programmer was, instead of having a candidate solve some abstract complex puzzle (worthless), the candidate should instead be asked to implement a very simple, rudimentary piece of code. You may think this only weeds out amateurs. Not so. Many a Comp. Sci. grad can fall into this trap as well.

But what separates a 10x developer from other junior and senior developers is their ability to not only produce code to solve problems, but to read / comprehend the solutions that have come before them.

In the real world, developers are constantly tasked with maintaining the work of others. It is one thing to know your own code; it is an entirely different skill to untangle the spaghetti that others have left for you to clean up. 10x developers produce and consume with high efficiency.

Distraction Free

If there's one thing a 10x developer cherishes, it is flow. Clamping a pair of headphones over their ears is the same as hanging a DO NOT DISTURB sign outside their door. In a landscape of open office plans, Lumbergh-style managers, needy fellow employees in a Slack channel and the constant blip of social media alerts popping on their phones, a 10x developers has practiced and developed the discipline necessary to stay focused on a task.

We could debate for hours where the responsibility in curtailing distractions lies (bring it!) but for now, let's be clear: regardless of distractions (or who caused them), a 10x developer can successfully tune them out.

Tool Proficiency

If you've got a masochist on your hands who lives and dies by their vi editor, hey...more power to them. But are they compiling by hand? Are they linting? Do they deploy their builds manually? How are they debugging? How easily can they move between bug fixes and feature requests? Where's their code stored and can their changes be recalled historically? Many expert developers claim they still look code up (perfectly fine!) but how do they look it up? More importantly, are they leveraging any sort of programming tool that might look it up on-the-fly?

Both amateur and expert programmers alike have tools and processes they prefer. But a 10x developer is not wasteful when it comes tooling. They will automate what they can. They take advantage of IDEs that guide their development. They take the time to build the necessary infrastructure that allows their development processes to scale.

A comment debating the existence of the 10x developer recently made the claim that this was illogical when comparing to other industries, positing "how can can a construction worker be 10x faster than another?"

Simple: Construction workers don't bash nails in with their bare fists...but using a hammer and using a nail gun produce vastly different turnaround times. 10x developers know this secret and leverage tools appropriately.

Troubleshooting Strategy

Fixing bugs is a part of every programmer's life. The efficacy of each programmer's problem solving technique can vary from person to person. When it gets down to the line-by-line examination of faulty code and its matching bad behavior, 10x developers look to diminish the impact the malfunctioning system has on its customers.

If an urgent system is offline, a 10x developer knows what steps to take now vs. later to resolve the issue -- a key differentiating factor from an expert, as some "experts" will always insist on the full end-to-end solution, keeping the system offline in the process.

I once deployed a bug fix that caused some dependent systems to behave badly. Thanks to behind-the-scenes logging, I was able to assess the situation and identify a bug fix pretty quickly. Once I was ready to push it out, however, I was stopped dead in my tracks by a DevOps team that insisted on rolling everything back and starting an entirely new build. When I attempted to communicate that the rollback impacted database schemas, risking additional hours of downtime -- while my fix would deploy in seconds, someone on the conference call pushed back, claiming:

"Uh, this is IT 101 folks"

No. "IT 101" is evaluating your options to determine the least amount of impact to your customers. If given the option between online now and online hours from now...you get it online now, and make the next step your long term fix. Process is great, but not if it gets in the way of progress.

Remember, kids:
  1. An amateur band-aids over a problem.
  2. An expert applies a solution to a root cause.
  3. A 10x developer gets the system back online.

Quiz Time!

Let's see how closely you paid attention: What's the one thing in common with all of these traits?

Answer: all of these traits impact turnaround time:
  • How fast one codes. 
  • How fast applies existing solutions to new problems. 
  • How fast one converts a business challenge into an algorithm.
  • How fast one gains (and retains) flow.
  • How fast one can "build to production." 
  • How fast one can get an unserviceable application back online.
And remember...It's not just about speed, it's about how long it takes someone to produce quality output and call it done. In some cases (like typing) yes, speed of execution matters greatly! But with others (such as building to production) its about enhancing one's ability to perform the task (ie. via automation) that separates 10x developers from the rest.

And here's the other secret: there are actually plenty of 10x developers out there. You know what they call themsleves?

"Developers"

And the reason why is: their accelerated turnaround times don't emerge until their compared with slower folks that:
  • Can't type,
  • Don't have the experience / skills to apply old solutions to new problems,
  • Have never practiced converting business challenges into code,
  • Lack the ability / skills / concentration to enter distraction-free flow,
  • Don't know how to automate their processes,
  • Are focused on bug fixes rather than system uptime during a crisis.
But now that the bullet points are as plain as day, they can start now. And so you can you.

Popular posts from this blog

Sad Stories

How are you measuring the quality of your product management? Is it: How accurately you adhere to Scrum?  How close your velocity matches your SLO?  The number of bugs fixed in this sprint? None. of. this. matters. A surface level review of these metrics would seem to matter to folks desperate to boast about their Agile compliance, while failing to remember the first edict of the manifesto : Individuals and interactions over processes and tools A recent tweet reminded of this: Wow! I reported a unicode issue affecting URLs to 2 different commercial software companies. One responded in 4 days indicating it'll be fixed in a yet-to-be released new version (which requires more $$$); the other provided a working patch in less than 3 hours. — James Moberg (@gamesover) June 18, 2019 While I can't comment on what specific bottleneck is separating these two companies, I understand (all too well) the side-effect of throwing everything into a Scrum bucket. Af...

Tired: 10x Developers. Wired: 10x ENVIRONMENTS.

image: the mythological 10x developer, caught in its natural habitat. A 10x developer thread blew up on Twitter over the weekend. A startup/disrupter posted their tips on how to find the mythological 10x engineer and what massive rewards your organization will reap by having one. Unfortunately, their "tips" only amounted to the perpetuation of a very different type of engineer: one who can't mentor, can't be bothered to attend a meeting, knows only code (to the detriment of all other soft skills), and will insist on doing things the right way...aka their way. In short, it was a list of attributes that described a toxic developer. After having slung code for two decades...and am now charged with leading my own team of developers...here is the harsh truth of the matter: If you want to build a team of highly productive developers, focus on building a 10x environment . Build knowledge sharing into your process, so your team is actively invested in educa...

How Do I Use Myers-Briggs To Assess My Team?

Question: How do I use Myers-Briggs to Assess My Team? Answer: You don't. Seriously. That's my answer.  Don't do it. Still reading? (sigh) Alright, if we're going to do this dance, let's get it over with. Myers-Briggs is Junk Science When a hypothesis is tested in a controlled experiment, proven, and those results are vetted by independent peers, you have yourself a little thing we like to call scientific evidence. Leave any of these on the table (eg. you make a hypothesis but don't run an experiment), all you have is opinion . The missing piece in Myers-Briggs (or MBTI) is that last part: independent verification by peers . Scientists uninvolved in the hypothesis need to be able to reproduce the experiments and put their career on the line by saying, "Yeah, this other scientist I don't know anything about...they're 100% correct." The only "verification" that Myers-Briggs has is via the Center for the Application...