What is a 10Xer?

My wife read an article about programmers in the New Yorker and we had a discussion about '10Xers'. I felt inspired to explain a little about this.

So there is this idea that some programmers are 10 times as effective as other programmers. It is usually mentioned when hiring engineers. If some engineers are 10 times as effective as others you definitely want to hire them. If you have to pay one of these 10Xers three times the money it is still a very big win!

People have various reactions to this. One common one is to say it isn't true. The reason behind this denial is the denial of the idea that some programmers are super geniuses who are just at one with the code. Every programmer breaks the build. Every programmer generates bugs. Every programmer interacts with people who know a lot more about certain parts of a system than he does. Some people manage to keep a certain level of arrogance despite this, but programming can often be a very humbling job and the notion that some of us are some how super-geniuses goes against this.

I pretty much reject the notion of super developers that somehow output ten times the amount of functionality, but I do acknowledge the idea that some programmers are "10Xers". Here is a story of two developers that hopefully illustrates my point. Their names are Ten and One.

Requirements come in. They aren't particularly good.

Ten: Ten identifies problems in the requirements. He spots places where they have gaps or ask for things that are very difficult compared to the value they give. He immediately gives feedback on these and gets them corrected quickly.

One: One says okay to the requirements. He goes forward coding. He discovers the problems later. Maybe he tries to solve the wrong problems and spends his efforts on things that don't matter. Eventually he goes back and tries to get the requirements to make sense. 

Writing the Code

Ten: Ten knows how to structure things and builds a good infrastructure. He has patterns in mind for most problems. He writes clean code. He bangs on the keyboard at the exact same speed as One, but his lines often do a little bit more. 

One: One hacks together a bunch of hard to understand crap all in one big object with everything globally scoped. He does this because it is "easier" and "quicker". One often writes lines that aren't useful and his code may have repetitive parts. One might use a lot of copy and paste.

Finding Bugs

Ten: Ten has some bugs in his code. QA finds the bug and starts the process around fixing the, verifying them, and so on.

One: One has lots of bugs in his code. There is the same process, but the number of bugs increases the time it takes. This causes schedule pressure.

Fixing Bugs

Ten: Ten's code is easy to understand and fix. Bugs are handled quickly.

One: One's code is hard to understand. Bugs are hard to understand because the code is difficult to work with. The likelihood that one bug fix introduces a regression (breaking something that used to work) is very high.

New Features

Ten: Ten's code may or may not handle new features well, but it is easy to modify and maintain. Structures can be modified without introducing a lot of new bugs. Structures Ten made in the past may be reusable. This already QAed code gives a big leg up when adding functionality.

One: One's code is very hard to understand. Adding a new feature is very difficult. It introduces lots of problems. Old code can't be reused forcing all the code to be new and untested.

Development Environment and Tooling

Ten: Ten finds pain points in the process. He makes or finds tool that make the whole process easier and less error prone.

One: One doesn't do this. He lives with the pain and does things slower and in a more error prone way.

Hire More Guys

Ten: Ten has accomplished his tasks. There is no need to hire anyone else.

One: One is now behind schedule. You get a new hire. His name is Uno. He has trouble reading One's code. He doesn't understand it and has communication issues with One. They aren't big ones, but he needs to have a lot of things explained. When he writes code he then needs to explain things and coordinate with One. Sometimes One and Uno work on the same code and have merge issues. This takes up a lot of time. Enhancements and styles One might develop aren't used by Uno and vice versa. 

Hopefully this story showed how differences in ability can affect the software development process in a lot of ways. So even if one developer has slightly more ability than another, the natural multiplicative effect of the process will make a large difference in what they can deliver.