The closer you get to the top...
In many types of human endeavour, the better you get, the smaller the gaps are between you and your peers. In sports, for example, there are big gaps between the bad 100m runners, but the top 10 are all within a second (or less) of each other.
In programming, the closer you get to the top, the bigger the gaps get. An average programmer can easily find many peers with roughly the same abilities as himself. A great programmer often has no peers within a factor of two of his own abilities, if not more.
Don't believe me? I just got back from the 2005 ACM east-central North America regional programming contest. Teams of three programmers get one computer, eight problems, and five hours to solve them. The solutions are programs that produce the correct output for every set of input the judges care to test them with.
Here are the full results.
Out of 111 teams competing, 54 failed to solve any problems, 29 managed to solve one, 14 solved 2-3 problems, 9 solved 4-7 problems, and 5 solved all eight. Notice a pattern there? Every doubling of the number of problems solved halved the number of teams that were that good. This is a consistent pattern that appears every year. I suspect it appears in every region too.
It gets worse. As part of the contest, submissions are timed. Of the 5 teams that solved all eight problems, times ranged from 2:33 for the 1st place team to 4:56 for the 5th place team. The 1st place team was twice as fast as the 5th place team. The biggest gap in the top 5 (1hr 7min) was between the 1st and 2nd place teams. The 1st place team didn't train more or have better teachers than the 2nd place team; they were from the same school and trained together.
In programming, the closer you get to the top, the bigger the gaps get. An average programmer can easily find many peers with roughly the same abilities as himself. A great programmer often has no peers within a factor of two of his own abilities, if not more.
Don't believe me? I just got back from the 2005 ACM east-central North America regional programming contest. Teams of three programmers get one computer, eight problems, and five hours to solve them. The solutions are programs that produce the correct output for every set of input the judges care to test them with.
Here are the full results.
Out of 111 teams competing, 54 failed to solve any problems, 29 managed to solve one, 14 solved 2-3 problems, 9 solved 4-7 problems, and 5 solved all eight. Notice a pattern there? Every doubling of the number of problems solved halved the number of teams that were that good. This is a consistent pattern that appears every year. I suspect it appears in every region too.
It gets worse. As part of the contest, submissions are timed. Of the 5 teams that solved all eight problems, times ranged from 2:33 for the 1st place team to 4:56 for the 5th place team. The 1st place team was twice as fast as the 5th place team. The biggest gap in the top 5 (1hr 7min) was between the 1st and 2nd place teams. The 1st place team didn't train more or have better teachers than the 2nd place team; they were from the same school and trained together.
2 Comments:
Definately interesting, but here's some food for thought. You compared runners to the teams of programmers... runners are solo. Consider this: competitions involving solo competitors require those competitors to rely on themselves... its also kinda obvious that there would be little difference between the good runners.
However, when you have a team, you also have to take into account that members of that team will attempt to improve their chances by teaming up with other people that are as good (or better). Especially in the case where you said the two teams were from the same school. The three best in the class teamed up with each other knowing that they would have a better chance working together... which left the next team to choose from those left. If the programmers had been equally distributed... 1 excellent, 1 average, 1 not so good per team... they would probably have been more equal.
Its kinda the same reason why Michael Schumacher kept winning so easily in the previous races... its not a coincidence that his pit stop crew got awards as well... it was a team of skilled people helping each other... improved the chances of winning well over the others.
I just had an offline conversation with a professor who asserted that the distribution I observed is present in most professions, but to a much lesser degree (i.e. best is 4x better, instead of 100x). His assertion is that nobody, in fact, teaches programming, just theory. Therefore, all programmers are self taught. With a little training (he says) we could get all the programmers to within a factor of 4 of each other.
Post a Comment
<< Home