Sep 8, 2016

The 10x Programmer


Who is the 10x programmer? How do you know one from the other? How do you hire a 10x programmer? There is this perception I have seen about the 10x programmer who is this insane work machine, who can spit out code faster than most can type. I feel the term is highly misunderstood.

Lot of people think developing software is a linear task. That productivity is directly proportional to number of commits, lines of code and number of hours spent. I even came across a startup that provides tools to measure team productivity and performance using those stats. Those are not fun places to work at for a programmer.

To understand the 10x programmer is to understand what writing software is. Writing software I think is a form of art. If I compared paintings in terms of how many shades of colors were used or how many gallons of paint went into its making, would that be a fair evaluation? Or how about measuring the quality of a book by the number of pages / words written?

A piece of code solves a problem. A good piece of code solves a pattern of problem. An excellent piece of code solves the right pattern of problem. And that is what the 10x programmer does. They solve the right pattern of problem.

To know the right pattern is no trivial task. Not many can see those patterns. For someone who does not understand art, all paintings are more or less the same. Leadership that don't understand this, will not appreciate the 10x jobs hence will eventually loose the programmer or the gains.

To hire the 10x programmer thus is also difficult. One needs to understand not only how they solved certain problems but also the context and the alternatives. The spark of genius does not necessarily light during the hour of the interview, hence it needs to be derived going into the details of the past. It would help to see how they understand a problem v/s solving it. An alternative approach to hiring 10x programmers is to spend time identifying those from existing team. Then nurturing them to grow and solve larger problems.

Comments