The 100x Engineer

A few months ago a new engineer joined our team. As always I spent some time with him to better understand the type of person he is, what drives him. We usually talk about past experience, but more importantly: future goals. As it turned out, he had an interesting one:

I want to be the best programmer in the world

That’s quite ambitious.

I liked it.

However, this made me consider — what does that mean, actually, to be the “best programmer.” How does one measure that, how does one know he or she is it?

That reminded me of a paper from the 1960s written by Sackman, Erikson and Grant entitled “Exploratory Experimental Studies Comparing Online and Offline Programming Performance.” The goal of this study was to investigate the difference in programmer performance in various aspects of programming given whether the programmer had interactive access to a computer — mainframes at the time — or was effectively working with “pen and paper.” While the answer to this question has pretty much become obsolete — who programs on paper anymore—still there were a few findings that have lived on to this day:

• There is a 20x difference in programming time to complete a programming exercise between the best and the worst programmer among the research participants.
• There is a 25x difference in debugging time.
• There is a 5x difference in the size of the programs produced.
• There is a 10x difference in the program execution speed.

The research participants all had a few years of experience under their belt, in fact the years of experience did not seem to have a significant impact on these numbers. All in all, quite a significant difference, no?

The 10x Programmer

This paper is where the concept of the “10x programmer” originates. It has fascinated people for decades, and is highly controversial. Just Google the phrase.

To be fair, Sackman et al.’s numbers for sure were exaggerated, many have challenged their methods. Still, few dispute there are significant differences between poor and amazing programmers, even anecdotally everybody knows somebody who seems to build amazing pieces of software in shockingly little time.

“So… who cares?” You may be asking. Why are 10x programmers such a big deal?

Well, for one, at least ostensibly, 10x’ers are a good deal for employers. Conceptually they can do this:

1. Fire 90% of the workforce
2. Hire 10x-ers for the remaining 10%
3. Pay them perhaps 2x
4. Profit

Simple, right?

Reality, however, looks a bit different. First off, this assumes you are able to hire a team of 10x’ers, and… good luck with that. And since you probably won’t be able to do that, you have to integrate them into your existing single-digit-x’er team. As it turns out having somebody in your team who’s significantly, significantly more productive than you is not all that motivating.

But actually, I didn’t really want to dwell too much on the concept of 10x programmers, because from my perspective, there is a different “breed” whose impact far exceeds that of the 10x programmer.

Who?

For that let’s first have a closer look at the term “programmer.” In the Sackman research, they focused solely on programming ability. Exercises were highly algorithmic, of the type “given a grid representing a maze, write a program that finds a route to the exit.” And this is the type of work that good “programmers” are good at: programming challenge in; code out. Every programmer has their own queue of such tasks, and is knocking them out, one by one.

Typin’ the codez.

And if that’s what you like, I’m sure there are places where you can work that way.

However, this is not the programming reality in any place where I have ever worked. And to be frank — thank god. Long term, I think this gets really boring.

A role that I find much more interesting is the role of engineer. Engineers turn ideas into actual working products and thus have a much wider perspective. They have a whole slew of tools available to them to get the job done, and of course, programming is one of them.

But to be frank, and I think I can say this here, for a skill we tend to brag about so much, we’re pretty damn bad at it.

Statistics don’t lie:

(a) Industry Average: “about 15–50 errors per 1000 lines of delivered code.” He further says this is usually representative of code that has some level of structured programming behind it, but probably includes a mix of coding techniques.
(b) Microsoft Applications: “about 10–20 defects per 1000 lines of code during in-house testing, and 0.5 defect per KLOC (KLOC IS CALLED AS 1000 lines of code) in released product (Moore 1992).” He attributes this to a combination of code-reading techniques and independent testing (discussed further in another chapter of his book).
(c) “Harlan Mills pioneered ‘cleanroom development’, a technique that has been able to achieve rates as low as 3 defects per 1000 lines of code during in-house testing and 0.1 defect per 1000 lines of code in released product (Cobb and Mills 1990). A few projects — for example, the space-shuttle software — have achieved a level of 0 defects in 500,000 lines of code using a system of format development methods, peer reviews, and statistical testing.”

I say — we should avoid programming whenever we can and save the world from all those bugs we introduce every time we press a key in our IDE.

So yeah, the 10x programmer… cool idea. But I’d to set the bar a bit higher. It’s about to be 2018, the world has changed.

The 100x Engineer

I like stretch goals. They often lead to taking a step back and to big shifts in thinking. And so does this one. If we want to be 100x engineers — engineers who have 100x the impact of ye’ old 1x engineer—how do we accomplish that?

Being productive yourself is not enough — 10x you can possibly achieve by sheer programming talent, sure, but not 100x.

In order to have a 100x impact, you have to multiply that productivity across your team and organization, and, ultimately, guide others to that same way of working.

While 100x may sound extreme, I have worked with various people in my career that I consider to have the “100x mindset”, a particular way of thinking, talking, and acting.

What may be surprising to some people is that none of this has anything to do with programming ability, technologies, nor programming languages. The common cry is: “Why are we still using Java? If we could only use Scala, Clojure, Node, <> we would be so much more productive!” The reality is a different programming language perhaps gets you to to 1.5–2x tops. That’s peanuts to 100x stuff. 100x is a different game altogether.

So, what is that “100x mindset” exactly? Let me discuss two aspects.

1. Ownership

100x’ers own what they do. They know the why, they know the how, and the what of what they do. In the book “Extreme Ownership” two former navy seals explain their concept of extreme ownership. The core of the concept is exactly what I mean when I say “own things.” It means: accepting that you are accountable for everything you do.

Most importantly that means: no finger pointing. This doesn’t mean that everything is under your control, but it does mean you are responsible for how you react when things inevitably do go wrong. It means you are responsible for anticipating what could happen and have contingency plans. It means you learn from mistakes to get value even from them. Own every aspect of what you do.

I only know of one way to get to this level of ownership: by challenging things; by productively challenging everything that is asked of you and your team, so you understand and can own every single decision.

2. Challenging the status quo

The 100x engineer challenges things in three dimensions:

1. What? This is primarily about scope: what are we developing, and is this scoped well, is everything clear in terms of requirements, and are we sure that all of it is important and needs to be done (right now)?
2. How? This is about being smart about how something is implemented, are there less-effort ways to get to the same result? But also about process: how do we get to the results we want and how can we improve?
3. Why? This is about business context, about fully understanding why a feature need to be developed, and to check that the product manager’s approach is the right way to fill the user’s need.

Let’s look at each in a bit more detail.

What

The single best way to deliver a product faster is to cut its scope. What are the features it needs to have.

We can apply my “5 really’s” technique here:

PM: We need to have all these 10 features
100x’er: Really?
PM: Yes.
100x’er: Really?
PM: Well, ok, maybe not feature 7. But for the rest: yes.
100x’er: Really?
PM: Yes, well, I think so… Let me verify with the customer.
Ok, they may need 4 and 5, but we can do this later. The rest are all must-haves.
100x’er: Really?
PM: Yes.

This may sound like a joke, but more often than not a product manager shows up with a long, long list of features that are all must-haves. Then, after hours, days, sometimes months of negotiation, you end up with a list that’s barely a quarter of the original one. This is only natural, coming up with new features to add is easier than to remove them.

Another way to reduce scope at a lower level is by using the “pareto principle,” the 80/20 rule. Wikipedia:

The Pareto principle (also known as the 80/20 rule, the law of the vital few, or the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes.

This rule has many applications, and software development is one. Quite often there are ways to implement a feature that is significantly less effort (20%, say) but gives you most of the benefit (e.g. 80%). This is not only attractive because, well, it’s less work, but also because this allows you to cheaply test out features, and only fully develop them when they turn out to be valuable and used.

How?

Now that what needs to be developed is reduced to a minimal set, there’s still a lot of wiggle room and wins to be gained by challenging how things can be implemented. Generally there are many ways to implement a feature. In many teams as soon as the groups comes up with one approach, they’re satisfied. 100x’ers will always push to find alternative approaches, to evaluate all options based on their pros and cons.

The “how” can also be impacted by technical debt. Often there’s a “hacky” way to implement something quick and dirty, and a “proper” way that first involves cleaning up technical debt, and then implementing a feature cleanly. What is the best way? The 100x’er appreciates there’s not one true answer, and it really depends on the circumstances and cost of accumulated technical debt. A 100x’er can make the right call case-by-case, and negotiate with product to get the time to reduce technical debt when appropriate.

Another aspect of “how” is the process. What I like a lot about Scrum is that it effectively sets up a foundation that, when used properly, encourages 100x behavior:

• Refinements are a great forum to discuss and challenge the what, the how, but also the why. The product owner presents new features to be developed, and the development teams challenges the what and the why to get the full context and challenging each other on how to implement it.
• Plannings beside deciding what to do the next sprint, the planning is also a means to “prime the mind”: to remember what needs to be done exactly and plan how the team will cooperate to deliver.
• Retrospectives is where the team gets better. Some things go wrong during a sprint cycle, some things go poorly. The retrospective is the time where the 100x’er challenges the team to improve and do things better next time. And here too: practice ownership. 100x’ers don’t complain unproductively. They don’t point fingers in any other direction than their own.

Why?

Just last week I had a conversation with an engineer who just found out that he had spent 3 months full-time on implementing a feature, and then found out that the same value to the user could have been realized in 3 days of work. Obviously, it wouldn’t have been the same functionality, but it would achieved the same goal.

How can something like that happen?

This will happen unless engineers take a step back, zoom out and challenge the why. Why is this feature to be developed? What is the user trying to achieve? What is their need? Product managers tend come up with very specific feature requests, sometimes specified at a very low level. This is meant well, however, chances are that product managers are humans too, and miss things. Additionally, the risk is that engineers no longer challenge the much more fundamental question: why are we doing this, and isn’t there a different way to achieve the same result with less effort?

But wait…

All of this is easier said than done. And it should be, not anybody should be able to reach the ranks of the 100x engineer. Nevertheless, we can all aspire to, and figure out ways to get better.

Therefore, it is worth looking at the skillset of a 100x engineer. As you will notice, it is very, very different than of 10x programmers.

• Communication — this one is almost too obvious to mention, but it’s an important one. 100x’ers have excellent communication skills. Communication is an essential part of having 100x impact.
• Creativity — obviously this is common with 10x programmers, but the creativity required is not about algorithms, nor clever class inheritance structures, rather it is about coming up with more effective ways of achieving goals.
• Empathy—somewhere buried in all this “challenge everything” talk, I mentioned “productive challenging.” So what did I mean by that? Let me explain using my oldest son as an example. He is 4 years old. What is the favorite question of a 4 year old? “Why!?” Does that mean my son is a 100x engineer? No. Why not? Because he asks “Why?” always. Whether it’s a good time or not, whether it makes sense or not, whether he makes his parents want to kill themselves or not. Having the empathy of knowing what to challenge, how, and when is an essential skill of the 100x engineer as well.
• Negotiation—good ideas are overrated. Everybody has them, but few manage to execute on them. An essential element of being able to implement ideas that you know need to be implemented is negotiation— negotiation with fellow developers, with product managers, and with other stakeholders. Explaining why the idea is good, and why time should be allowed to implement them. 100x’ers know how to do this, as a result everything seems possible when they’re around.
• Technical—last on this list, but still vital. While most skills mentioned are quite “soft,” this does not mean the 100x engineer needn’t be technical. In fact, it’s a prerequisite that he or she is technical top talent, for two reasons: (1) challenging things at the technical level yield big gains, and therefore require a deep level of technical understanding, and (2) ethos matters, 100x engineers wouldn’t be accepted by their peers if they weren’t strong technically, you have to be “one of us.”

A few months in, mister “I want to be the best programmer in the world” is doing very well, as a programmer. He’s talented, works very hard, is productive and very smart. Will he be the best programmer in the world? I don’t know.

But secretly I hope that it won’t matter.

I hope that some day, not now, but maybe in a few years, he will want to do something more. That he will adjust his dream to not just be good at one narrow skill called “programming,” but will aspire to have the impact of a 100x engineer.