how the concept of a 10x programmer arose and what stands behind it
Superhero or myth: how the concept of a 10x programmer arose and what is behind it
Everyone who is somehow connected with the IT sphere is familiar with the concept of a 10x programmer. This is the name of the coolest and most effective developers. The term is found literally everywhere: from clickbait articles “How to become a programmer in a month” to books by respected experts like Steve McConnell or Martin Fowler. Even in the series “Silicon Valley” in the very first episodes it is mentioned that the main character is just one of those same 10x programmers.
All articles on the topic refer to some research scientists. I figured out how 10x programmers appeared and what is really behind this term.
Another order from the military
In 1966, a research team of two employees of the System Development Corporation, Eugene Grant and Harold Sackman, commissioned by the US Army, compared the performance of experienced programmers (then not yet invented Seniors) with direct access to a computer and work through an operator.
In those days, in order to run the program, it was necessary to bring it to the computer center. The room, the size of a modern data center, could be occupied by just one computer with a single I / O point. Programmers gave their code in printed form or on punched cards to the operator and stood in line for its execution. Sometimes it took up to two days to get the result.
The alternative was the then-new concept of time sharing of computer computing resources between several jobs. With the help of a teletype, the programmer independently entered his program into the computer and almost immediately received the result. But all this took a lot of overhead: more expensive and complex equipment was needed, and context switching between users required additional machine time. Critics of this concept feared that programmers would be too lazy to check their own code, often run non-working and inefficient programs, and waste machine time.
To find out how each of these two approaches affects performance, scientists were commissioned to conduct an experiment. For him, 12 people were selected, who were randomly divided into two groups. Each had two tasks.
labyrinth – it was necessary to write a program to exit the labyrinth presented in the form of a 20×20 table.
Algebra – it was necessary to write a program that could interpret an algebraic expression entered via teletype and solve it. We also needed to handle input errors, if any.
Direct access to a computer | Indirect access to a computer | |
Group 1 | Algebra (6 people) | Labyrinth (6 persons) |
Group 2 | Labyrinth (6 people) | Algebra (6 people) |
Both tasks of the group had to be solved with direct and indirect access to a computer. To simulate work through the operator, the organizers of the experiment hired two students and set a number of rules. According to them, the participants in the experiment could:
give the code only from 8:00 to 17:00
instruct the operator what and how to enter
ask to print debug information
run no more than 2 programs per hour at the same time
receive the result in 2 hours, provided that it is submitted before 15:00, otherwise it could be ready only the next day
To write the code in the experiment, a 60-ton IBM AN / FSQ-32 transistor computer, which was originally created for nuclear bunkers, was used. It supported the concept of time sharing between users and had several teletypes to work with. As a programming language, the subjects could choose between JTS (Procedurally Oriented Language “JOVIAL Time-Sharing”) and SCAMP.
What is the myth based on?
During the experiment, scientists measured the time spent by the participants on writing a working program, and the computer time required for test runs. They also compared the size of the resulting programs and the speed of their execution.
As a result, scientists made several conclusions:
With direct access to typing and executing the code, the result can be obtained much faster. Mostly because there is no delay between entering the code and getting the results.
If programmers are allowed to run programs on their own, then they begin to spend an average of 30% more computer time.
Scientists have also noticed a significant gap in the productivity of programmers. Despite the high qualifications of all participants in the experiment, the difference between the best and worst results was very large: from 5-fold to 28-fold. At the same time, scientists did not find a direct correlation with either work experience or grades in standard tests for programmers.
Performance evaluation | Worst result | Best result | Coefficient |
Algebra debug time | 170 | 6 | 28:1 |
Labyrinth debug time | 26 | 1 | 26:1 |
Elapsed Algebra CPU Time | 3075 | 370 | 8:1 |
Elapsed Maze CPU Time | 541 | 50 | 11:1 |
Labyrinth development time | 111 | 7 | 16:1 |
Algebra development time | 50 | 2 | 25:1 |
Algebra program size | 6137 | 1050 | 6:1 |
Program Size Labyrinth | 3287 | 651 | 5:1 |
Opening hours Algebra | 7.9 | 1.6 | 5:1 |
Opening hours Labyrinth | 8 | 0.6 | 13:1 |
The results were handed over to the military, and also published in the IEEE Transactions on human factors in electronics journal, with the note that this is the first known study of programmer productivity. It is interesting that in the same issue an article was published criticizing the conclusions of scientists. Its authors pointed out the limitations of the study and also criticized its parameters and methods.
However, in the seventies, Frederick Brooks referred to the conclusions made during the mentioned experiment in the book “The Mythical Man-Month or How Software Systems Are Made”. He summarized them:
In short, a programmer making $20,000 a year can be ten times more productive than a programmer making $10,000. Indeed, the opposite is also possible. The data obtained did not reveal any correlation between work experience and productivity. (I’m not sure this is always true.)
After the book was published, the existence of 10x programmers began to be spoken of as a fact. Since then, some companies have been looking for just such specialists, because it is believed that each of them is able to work alone for the whole team. Aspiring programmers look for ways to become “tenfold” and often burn out along the way.
Although, if you look, there is nothing fundamental behind the concept itself.
