I have definitely been involved in teams where removing the "top programmer" made everybody more productive. Usually, these developers are "10x programmers", in the sense that they write 10x the lines of code as the rest of the team, it's just all bad.
Maybe this is the distinction that throws off these "10x programmer" threads: the idea that a 10x programmer produces ten times the amount of code in a given time. The best programmers I have worked with frequently replace thousands of lines of code with hundreds. Programmer productivity is about value delivered, not lines of code.
The best programmer I have ever worked with used to be my boss. When I learned Perl, he had me write a very simple program to monitor some network printers. When I was finished, I showed him what I came up with and it worked pretty well.
I guess it was to show me that I was thinking too much like a C programmer, he rewrote my program in about 10 lines of Perl.
He was always willing to listen when I had design ideas that differed from his own. When my ideas were better, he'd incorporate them into our plans.
We had a four man team that was probably the most productive one of which I have ever been a member.
Exactly. Years ago, one company I was at proposed we start a bonus plan based on lines of code. I wrote a script that inspected the RCS commits (it was years ago) and generated a report that showed that most of our best developers were net negative lines of code.
1.) When I am stuck on hard problem, he is a good bet for help.
2.) History: was assigned tasks or project multiple people failed previously and was first to succeed.
3.) Tasks and projects assigned to him/her move with reasonable speed, does not need handholding. When other people take over, they don't complain all that much and are able to continue without encountering major wtgs.
Yes, I have seen that too, but that's not what I was talking about.
I have heard about a case where really the best programmer left, and now everybody else had more responsibility, had to learn about parts of the code they did not know previously, had to fix harder problems.
So, everybody else was getting better because the one person who could help with the hard stuff was not there anymore.
But I honestly can't remember where I heard that...
Ah, I've also seen that situation. But both times it was because the lead programmer was an autocrat who would scream at people if they did things wrong or revert their code or fail their code reviews, etc.
They were, as individuals, very productive, but they suppressed the productivity of the rest of the team.
That reminds me of "The Metamorphosis" by Franz Kafka. The transformation of Gregor Samsa (who was the family's the primary breadwinner) into an insect turns out to have a few unexpected benefits for the family. The develop self-confidence, regain health and skill, all that was lost because of their dependance on Gregor.
I have seen that with a guy that produced alright code, but was pretty bad leader - which was clearly his ambition. You either did everything exactly his way or had to argue for hours and days. The result was that whole project moved slowly, initiative people punished and parts of project he could not micromanage were mess anyway (since everyone else either left or was too passive).
