10x programmers? Let’s do the Math!

Many articles have been written about the famous Paul Graham’s quote about the productivity of programmers, where he says:

A great programmer might be ten or a hundred times as productive as an ordinary one…

It’s in an essay called Great Hackers, and it’s worth the read if you haven’t yet.

Interestingly, this was written ten years ago, but nobody cared much about it until recently when it started being used as a political reason for tech companies fighting to get more foreign programmers.

As with any political issue, you naturally get two sides, but I’m not gonna talk about this here. I wanna focus on the math instead.

First, let’s clarify that this multiplier between them is not an absolute constant. It varies from nearly one to infinity depending on a factors, like:

The complexity of the problem

The first variable that impacts the multiplier is the complexity of the program you ask the programmer to code. If it’s something elementary, very small that doesn’t require any thought, the multiplier gets close to one.

The easiest program of all, used in every first step or every programming tutorial, writing “Hello World” on the screen takes no time at all to code. It doesn’t matter if you got the best programmer in the world or the worst one.

On the other end of the spectrum, if you need something very complex, like creating a program to drive a real car from coast to coast without human supervision, the multiplier approaches infinity. The best 1% programmers will need several months at least to create it from scratch, the next 5% will take years, and the rest will probably never finish it successfully in their lifetime.

The main problem with complexity is that you can’t train people to keep getting smarter. You can teach them the tools, the techniques, you can inspire them, give them support, but you can’t make anyone able to solve any problem with coding the same way you can’t make everyone dunk a basketball. Some people will never be able to do that, no matter how much effort they put on it.

The distribution of how much complexity programmers can handle looks like a Normal distribution.

Creativity

People don’t realize it, but there is a lot of creativity required in a programming job.

When someone asks for a program or a feature, they don’t know if it’s possible, they don’t know how it should be done, all they know is the problem they have and how much time they can wait for it.

Since there are no rules about how to solve the problem, it’s up to the programmer to decide what to do.

Now imagine this kind of thing in the real world. Imagine you’re in SF and you wanna go to LA and you ask a programmer how to solve this problem. Bad programmers will not be very creative and get you a car or a bus ticket. A better programmer will set a ride-sharing app to pick you up and send you there automatically. But the absolute best programmers will design something like the Hyperloop.

Sometimes creative solutions save a lot of work, sometimes they cost more, but they might end up being infinitely better than the usual solution.

Creativity also can’t be taught and is also related to brain capacity, although from different areas. But if someone is struggling to find a solution to a problem, they will have no bandwidth left to create something that is better than everything that currently exists.

Teamwork

It’s very rare to find programmers working alone, mostly everyone work in a team and although this arrangement brings some great benefits, they also create communication and management costs, which might become the team’s bottleneck.

A bad or even a mediocre programmer in an otherwise good team will cause multiple problems that will slow down and annoy everyone else. How? Let me explain.

When programmers do “engineering” meetings, they spend the majority of the time discussing abstract concepts and ideas. If everyone is super smart, it’s an enjoyable time, quickly everyone is on the same page, the best decision is made, and the team can go back to their work. Add one mediocre programmer and he will take longer to grasp each piece, the meeting will be longer, less productive, less rewarding and you’re gonna waste everyone’s time.

You also have otherwise great programmers that are terrible to work with. It’s not rare to find people that can’t be a team player. So this grade is not just about ability, but also people skills, which a lot of programmers lack.

The worse the programmers, the more they need help and supervision from other team members. The briefings take longer, they come back more often for help, the final code will have more bugs, more lines of code (which is worse, trust me) and be less reusable.

Every time a programmer gets fired for technical reasons, the team eventually has to rewrite everything they did. So, the productivity in the worst case is negative, and it’s less than -1x since they waste time from everyone.

There is also a level where programmers create no value for the team, like a break even between the time spent keeping them on the same page and the output they produce.

The amount of gain/loss also depends on management. If managed correctly, each person can be put where they will help the most or at least not get in the way. Some good programmers can also coach not so good programmers into getting better, but this also has a limit.

Conclusion

Every programmer is a different person and being good at one of these categories don’t guarantee to be good at the others. That said, there is no doubt someone that can deal with h complexity is highly creative and a great team member is 10x more valuable than a programmer sitting in the mean of each of these traits.

If you wanna drop me a line, you can find me here.