Another Theory to Explain 10X Programmers

I fell into a role once that was unquely tailored to my experience. To paraphrase, I spent years studying and playing with parsing technologies, and parsing legacy languages for static analysis (these were my side projects). I took a job that required a lot of screen scraping (not really but close) at which I excelled. Blew everyone away when I turned around a project in two weeks. The same type of project took their devs three months on average. To them I imagine I seemed like a 10x'er. They didn't know I'd been writing parsers for fun, for years before that.

An example similar to this would be Brendan Eich writing Javascript in 10 days, when he'd been doing language implementations for fun.

I think a mix of things are coming into play here.

There is some innate talent involved in having the personality and mindset to easily think logically, and analytically. Likewise, the ability to jump to higher/lower levels of abstraction.

However, these are areas that people with different personalities can develop. Maybe the guy who comes to it naturally will pick it up quicker, but 5, 10, 20 years into a career, I suspect many people have balanced the playing field.

The mini-skillsets referred to in the article do come into play, as does the experience of what problems, industries, etc, one has worked on in their career.

At the end of the day, I think the overall idea that one person may be 10X in one situation, but 1X in another is 100% accurate.

Using myself as an example, I excel when working on old IBM legacy platforms to manage document-based applications, and modernize them to today's web UI expectations. That has been my specialty for about 10 years now, and I really am quite good at it.

But aside from HTML, CSS, JS, I don't know squat about the tools used by the startups who are writing thigns from scratch these days.

So at the end of the day, I am at least a 10X programmer in my little niche, but would not even pass a phone screen for a YC company.

The flip side is also true. The "rock stars" in SV would crash and burn if they had to do some of the things I do, as they would have to learn old legacy platforms that would be archaic and depressing to them.

And yes, this situation is problematic for my long-term career, but seems to be a great example of how different skill sets perform vastly differently depending on the project.

There are 10X programmers. I'll give an example. If you take an average programmer and "the best of the best" and ask them to build a relatively complex iOS app, of which neither has previous iOS experience, the best programmers WILL finish the task up to 10x faster than the average. This is because the average programmer gets stuck on bugs, solving problems, complexity, and is slower at learning new things. The better programmer has a combination of skills that allows him/her to do the correct research and solve the problem at a much faster space. The rate of which grows as the complexity of the task increases. Thus reaching 10X.

I don't really agree. Consistent 10x programmers learn the skillset required for the job. Often that requires learning about topics that have little relevance in other jobs. Because of that there is little incentive to be a 10x developer. They are paid maybe 1.25x-1.5x average and have to put in 3-4x the effort.

For example I am a 10x developer but much of my knowledge is company specific. This means I simply don't have much leverage; I am already paid 1.5x market rates. I could only change to a better job with a company that was willing to take a 3-5 year "gamble" on me. Unfortunately the average dev only sticks around for 1-2 years so companies don't usually make these long term hires.

For example I recently spent 50 odd hours of my own time learning the ins and outs of our companies internal serialisation format. In other words I invested about 8 weeks worth of my learning time for no personal gain. The knowledge is not worth anything to any other company. It's not a rational investment.

I like this theory, seems to fit my experience and intuition much more than the "innate ability" kinds.

But then again, I'm a weird kind of programmer. I'm a 10X+ programmer when working on my own stuff, or some challenge, basically for fun. Start paying me or expecting me to deliver, and my productivity drops to 0.1X. I've been unsuccessfully trying to figure that out for years and fix my work productivity, with little result. I feel like I'm wired to be obligation-averse. The moment I have to do something instead of just wanting to, I lose all my skills.

A sports analogy appeared in yesterday's HN thread on this topic: the difference between an average runner and the fastest man alive is less than 50%. The counter argument here is that the measurable variable here isn't really the skill of the programmer but the success of the company (or equivalent). You only have to be best by a small margin to win. If you count wins between me and Usain Bolt he would be more than 10x as successful. Now you could argue that a lot of programming is just factory work; you can complete it in 20% longer time and your salary is lower by some factor. The truth is somewhere in between: a company with developers and other staff that are better than their competition by some factor, will go on to be a successful company a lot more often than others. The measurable business result could be thousands of times better. So what is being measured? We can't measure "skill" separate from experience, but even as a compound the interesting measure is the success of what you produce. If your product or service is earlier on the market or slightly better, you might have 10x the return of the "average".

My theory is that most programmers are really bad at it. The 10x guys are the few who actually know what they are doing.

I have worked with a lot of people in a number of different companies (including a few startups) and I can think of a couple of engineers who really stood out.

When discussing engineering problems with these individuals, I never had to explain twice - Often, I didn't even need to finish my explanation and they already knew the optimal solution for that problem.

These people are impressive to work with but I think it often comes down to experience more than intelligence (but they are usually very intelligent too). When an engineer has mastered a particular set of tools/languages/frameworks, they can come up with more optimal solutions and they can do it faster.

A deep understanding of tools and techniques allows developers to look beyond the most obvious 'naive' solution to find the one which is the most suitable (using existing tools to do as much of the heavy lifting as possible).

Also, when a developer cares deeply about a particular project, they will invest more time reading about relevant technologies in their own time.

When it comes to learning new tools, most engineers are content to 'learn as they go' - That's OK, but it means that they are not as well equipped when it comes to finding that optimal solution.

I think engineers should take time to familiarize themselves with tools REALLY WELL before they start using them, especially if such a tool/framework/technology will impact the project for many years in the future.

100x -> 10x "working memory" + 10x skill

---

"Programming Skill, Knowledge and Working Memory Among Software Developers from an Investment Theory Perspective"

Journal of Individual Differences 32(4), 201-209. doi: 10.1027/1614-0001/a000052.

PDF: http://folk.uio.no/gunnab/publications/BergersenGustafsson20...

---

And more research from Gwern: "DUAL N-BACK FAQ" : http://www.gwern.net/DNB%20FAQ

"Working memory is important stuff for learning and also just general intelligence. It’s not too hard to see why working memory could be so important. Working memory boils down to ‘how much stuff you can think about at the same time’. I magine a poor programmer who has suffered brain damage and has only enough working memory for 1 definition at a time. How could he write anything? To write a correct program, he needs to know simultaneously 2 things - what a variable, say, contains, and what is valid input for a program. But unfortunately, our programmer can know that the variable foo contains a string with the input, or he can know that the function processInput uses a string, but he can’t remember these 2 things simultaneously! He will deadlock forever, unsure either what to do with this foo, or unsure what exactly processInput was supposed to work on. .... "

Why are we debating whether some programmers are better than others? Of course some are. What we should be asking is whether hiring 10X programmers is worth it.

Today it seems every open position requires a "rockstar" developer, even for simple work. The demand for "rockstars" is so great, CEOs of tech companies complain of talent shortages, and companies resort to talent sniping. I suspect most programming jobs could be done well by an average programmer, thus ending the so-called shortage of good programmers and giving inexperienced developers the chance to further their skills on the job.

The whole 10X thing (which sounds like some superhero myth or whatever) is much simpler then we sometimes want to believe.

The work we do is not that unique. While often it will not be identical, but will share a lot in common. We learn what worked in the past in similar situation, and apply it successfully in the future.

That's it. Bottom line, experience matters a lot.

10X programmers are what they are simply because they've already seen a similar problem before. The longer you're at the game, the more exposure you've had the bigger the chance that you'll be 10X as good at something as somebody else.

Personally I don't think the 10X moniker is very useful. Imagine we'd be calling the marathon runners of the world 10X people. They may be a bit better at task 'X' (running a marathon) but they may suck at a variety of other tasks.

In the end it's all the 0.5 to 9.5 programmers that get the bulk of all the work done, and yet, everybody wants to hire only the 10X guys/girls and the not-yet-10X guys/girls are left to feel miserable because they're somehow inadequate.

If you want to go to the opera: practice, practice, practice. And then you too will be a '10X programmer' at some point in your life, the real question is whether or not you'll still enjoy it as much as when you did when everything was new and you were learning all the time.

One thing that I have noticed that makes a huge difference in your abilities: try to not be a single-technology programmer. If you branch out into at least two or three other sub-fields of programming (languages, theory) then you'll become a much better programmer in a hurry.

My belief is that a 10x programmer is one that codes for fun and because of that, has tackled a lot of different problems.

Problems solved for "fun" are very different from day job problems, but they often provide knowledge that can be applied.

It the extra knowledge what makes them great.

There's a story on the front page right now about writing a Haskell compiler from scratch.

I don't mean to be an ass, but I will: there are a lot of programmers that would effectively never be able to do this. We're asking about if 10X programmers exist? I'm saying even infinity X programmers exist.

I think a lot of this depends on the task at hand--some tasks are straightforward, others require a lot of, for lack of a better word, "invention", and that's where the difference lies.

If the task is "web front end to a database", that task is understood and executed on a level that there probably aren't many optimizations an individual can do. It's difficult to imagine someone implementing ten web front ends to databases in the time it takes an average programmer to do one.

On the other hand, if the task is "create a competitive AI to play the game of go", well, I think that there's a ton of invention required there, and an individual could in fact make a 10x difference.

Its basically a form of the fundamental attribution error. Instead of looking at the properties of the person, we would often be better to identify the tasks themselves as having the potential range 1x-10x. Some tasks admit a narrow band but others (with many bear traps and possible shortcuts) have a broad range. The actual productivity is the fitness of the developer to the task and not a property of the developer.

This "fitness" is how well their skills, their set of learned intuitions, personal characteristics e.g. courage vs. caution etc. fit the given problem which can be sheer luck. This lets us realise that a great developer can have experience that has trained intuitions that actually work against them for a given task and avoid the nasty labelling of them as "they are not a 10x developer".

That said, intelligence and focus are common attributes that undeniably elevate the baseline significantly but by how much? If only we had a way to quantify productivity to test this stuff.

My theory is that the best programmers are not spitting out too much code fast. They are the ones who thought of how to build the best app.

The best "building builder" is not the person who can lay bricks the fastest, but the one who can produce an awesome looking and very functional building.

I wonder what the "10x" ratio is for people like Paul Alen, or Marc Andreessen, or Dan Bricklin, or Dave Cutler, or Andries Brouwer, or Miguel de Icaza, or Bill Gates, or Tom Lane, or Markus Persson, or Linus Torvalds, or Bjarne Stroustrop, or Matsumoto, or (a personal hero) Grady Booch.

Maybe someone who has actually worked with some of these giants can tell us whether my theory holds any water at all.

It's not only about knowing how to build (the lots of tiny specific skills this article mentions). It's also about choosing what to build.

If you study what novelists say, they are extremely uncomfortable when they start new work. It's the same for 10x programmers. There is an initial torment and courage involved in that choice that deters the average programmer. That there will be skills one doesn't have for the new creation is a given.

There was a topic on rude programmers the other day and it got me thinking about all this labeling being the cause. VCs want to manipulate programmers, make them rate each other on artificial meaningless scale, call each other names, they even find new ways for programmers to offend each other, like that blob programmer thingy PG thought of. There is clearly an agenda.

Any programmer is capable of mastering anything in the field and be just as good as the best of the best. And it is very obvious that many tasks can be done much faster by someone with the specific skills these tasks require. It is also obvious that some people have a CS/CE degree and a broad spectrum of skills that are useful for many tasks and some acquired special skills on how to approach new unfamiliar problems more quickly by having and expecting to deal with a lot of different ones. And those things do not make a programmer into a 10x programmer or a blob programmer or whatever, just more or less adapted to some specific tasks.

I am dubious about the 10x theory as a whole.

It's really 10 times of what? Productivity? Value delivered to company?

A developer who convinces the CEO that the million dollar project to put in <crazy consultant lead idea>is a bit silly and you could just use a simple web framework on the cloud is worth 10x in value to the company all the other developers who would have happily built crazy idea for them.

Even if the consultants are all "rockstars" and the in house does php.

So I think that being always context specific (ie in this case I need memcheck, in the other case I don't use C at all so it is a useless skill) is too deep.

There are a set of skills called professionalism that mark a 10x developer

- the ethics of selling profitable services that are not in the best interests of the client

- the investment and training to remain upto date with the common best practises

- contribution back to the global corpus of knowledge on common best practises

I think that as a profession we need to work on building and encouraging all members to reach such standards.

Do we really know what the average programmer actually produces? We are all biased when deciding what is average as we use those around us to decide what is average - if we are surrounded by great programmers then our average is much higher than if we are surrounded by poor programmers.

The other complication is the intellectual energy hurdle that each problem brings. Some problems can only be solved by a small percentage of programmers, while others can be solved by anyone who can fog a mirror. How do we measure difference between programmers when the complexity of problems vary so much?

There's an old knowledge management idea called the "knowledge nugget," a definable chunk of knowledge, skill, and/or ability that can be captured, learned, stored, found, and shared. This chunking plays a big role in disciplines where the body of knowledge is vast, changes rapidly, and where just-in-time skill acquisition is likely. Aircraft maintenance calls for more info about more parts about different aircraft than any one technician could know; so they wind up doing lots of look-ups and following procedures and limiting studying to the most commonly encountered problems and to understanding classes of problems/solutions.

The first books on algorithms, like Knuth's, tried to chunk computer science. Software patterns tried this with newer ideas later. We've seen similar projects in functional programming, cloud architecture, and machine learning. The catalog of ideas/hacks is vast and, unlike with aircraft documentation/training, isn't centralized or organized.

Aircraft techs have a deterministic advantage over programmers: they have well-defined triggers and search parameters to find the relevant nuggets. The light that's blinking red has a part code and a serial number and docs can explain the the light's various states. Systems guide techs through decision trees to identify the right procedures for this problem. Programmers experience miserably vague and inconclusive cues.

Aircraft techs benefit from large but finite and known problem sets: just so many parts and so many interactions among them. Programming keeps coming back to ways to simplify and constrain the number of things that interact in ways that produce unexpected results. How much of OOP and FP aspires to help coders avoid complexity?

Aircraft systems are evolving rapidly, from one aircraft model to the next generation. But these have, for the most part, been incremental changes. Contrast that to the six-months to a year it takes to mature in your switch to function programming. Or new architectures, programming languages, and operating systems that require rethinking everything you know. The cognitive burden is high and the duty to relearn is weighty.

So your theory about nugget/task fitness producing moments of 10Xness and sum(nuggets)/sum(projects) producing days/weeks/months/years of 10Xness maps well to the knowledge management world.

Where are people getting this "10x" figure from and what is the significance?

Kind of makes sense. How do you rename a type that is used in 1000 places?

- someone will search and replace manually (hours);

- someone will search and replace with a regular expression (minutes);

- someone will use a modern automated refactoring tool (seconds).

in my opinion, it's all about time and motivation. I have neither, therefore i'm not a 10x programmer. but if i did, i could churn stuff out no worries.

but instead of that i spend a lot of time procrastinating and working like a 1x programmer in 1/10th of the time.

"He is..."

Completely agree on this. I don't believe in innate talent. I believe we are all born with the same willpower to acquire knowledge. Some people will be ok with not mastering any specific skill as long as it does the job. Others who are "passionate" about certain fields or skills will try to learn as much as possible. So "passion" is a better word to define people's skills.

I'm in the latter category, many people ask me sometimes how do I know so much about so different skills: from networking, security and system programming to web development UIs and design. The truth is I just spend so much time reading and practicing stuff that would seem boring to most developers around me. I spend nights trying to learn this new framework which seemed interesting enough to dig into it, and once I learn to use it, I want to know "HOW". How does it work, which problem does it solve ... and I think only passionate people can do this.