You can find discussions online regarding the idea of a “10X programmer”. Much of what you’ll find is ridicule of the idea that 10X programmers exist.

I’ve always thought it’s fairly obvious that 10X programmers exist. In fact, I think programmers vary by a factor of way more than 10X.

Months and years vs. days and hours

When I think of a 10X programmer, I don’t think of something who can finish a job in one hour what would have taken an “average” programmer ten hours. Rather, I think of someone who can accomplish ten times as much in a year than an average programmer. I think it’s a very reasonable proposition that one programmer could accomplish 10X as much in a year than another programmer.

When programmers vary beyond 10X

To me it seems clear that programmers can vary not just by 10X or 100X but by infinityX. This is because some programmers are so good that they can solve problems that weaker programmers would never be able to solve. In this case the better programmer hasn’t produced 10X as much value as the worse programmer, but infinitely more value. (I know that you can’t divide by zero, but humor me.)

My infinite variance claim doesn’t require the weaker programmer to be very bad or even below average. Some programming projects are really hard and require a really good programmer for the project not to fail.

Cumulative work vs. non-cumulative work

It’s not possible to be a 10X worker in every type of work. For example, the best dishwasher in the world is probably not 10X more productive than the average dishwasher. The world’s fastest ditch digger probably can’t dig 10X as much as the average ditch digger. That’s because a dishwasher or ditch digger starts each day with a clean slate. They can move their body parts a little faster but that’s all and then they hit a ceiling.

With programming, each change you make to a codebase influences how easily you’ll be able to make future changes to the codebase. The work you do today is helped or burdened by the choices you made yesterday, the day before that, and so on, all the way back to the first day of the project. Each coding decision in the codebase multiplies with some number of other decisions in the codebase, producing an exponential effect. Good coding choices can’t make your work get much faster, but bad coding choices can make your work slow to a crawl or possibly even a halt. When hundreds or thousands of changes interact with each other multiplicatively, it’s not hard for codebases to vary by a factor of much more than 10X.

How to become a 10X programmer

I think being a 10X programmer is mainly a result of four skills: communication, critical thinking, process, and writing good code.

Being skilled at communication helps reduce the chances of building the wrong thing, which wastes time. It also reduces the chances of experiencing interpersonal problems with colleagues which can slow down work.

Being skilled at critical thinking helps you arrive at right answers and helps you, for example, to avoid spending time barking up the wrong tree when debugging.

Following efficient development processes (small tasks, frequent deployment, automated tests, version control, etc.) helps you avoid wasting time on the overhead of programming.

Finally, writing good code (that is, code that’s easy to understand and change) can help make future changes to the codebase faster.

All four of those areas are very broad and many books have been written on each. It’s obviously not realistic for me to go very deep into those areas here. But if you want to become a 10X programmer, I think those are the areas in which to build your skills.