10 ms·

Everything from the original post sounds reasonable, you should absolutely read it. Just some random thoughts to add to it: * For most of my past clients, the

by struppi 10y ago

Everything from the original post sounds reasonable, you should absolutely read it. Just some random thoughts to add to it: * For most of my past clients, the skill / output of their programmers was not the bottleneck, even though they thought so. As long as something is not a bottleneck, there's not point in trying too hard to optimize it (since you can get better ROI somewhere else). * Software is a team effort. Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output (unless you are already very good at that). * Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team, regardless of how good they are. * I have heard of cases where removing the "top programmer" from a team made the whole team more productive, even though an important person was missing. I don't have data to back that up, though. Update: Thinking more about this... I have a talk called "Your Company Will Never be Agile", where I talk about how most companies actively prevent their people from doing a good job (by having policies, procedures and a company structure that is not suitable for empowered teams). And then, those same companies complain that they cannot get good people and how all the hip companies can get the 10x programmers that "we cannot hire". I don't have an English recording of the talk, but I started a series of blog posts about it: http://devteams.at/your_company_will_never_be_agile_intro http://devteams.at/your_company_will_never_be_agile_intro . I should maybe finish it some day ;)

Ensorceled 10y ago
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.
- struppi 10y ago
  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...
  - Ensorceled 10y ago
    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.
  - jansan 10y ago
    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.
- simonw 10y ago
  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.
  - Ensorceled 10y ago
    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.
    - dsacco 10y ago
      And how did you define and measure the "best developers"?
      - watwut 10y ago
        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.
      - Ensorceled 10y ago
        People getting important shit done.
    - icebraining 10y ago
      http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
  - LordKano 10y ago
- watwut 10y ago
  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).
sametmax 10y ago
Come on, Antirez is a x10 programmer, he coded one of the most brillant software of the last decade. It's so well done I use it as an example in my trainings, making people compile it to stop being afraid of building from source because I know it never fails and it's so damn simple. And programmer reading anything on his blog, or anything on HN for that matter, is not an average programmer anyway. The simple fact you are interested in your work singles you out. Guys, you need to come out of your super power bubble and come to work down here. Where people uses PHP, SVN, and don't know what an environment variable is. Where they work for money, not for passion. Where Vi is scary and they pay the licence for Oracle even if their DB has one table. This is the huge majority of the devs : plumbers. I find it disrespectful when people don't realize this, because it means they live a life ignoring a vast majority of dev tool users. Not only those people are numerous, but they create a lot of wealth because they are so many. Don't assume: - devs know the command line - devs know how to setup a server - devs know how to use a package manager - devs know how to version control, unit tests... And above all, if they don't know how to do that, don't assume they can't do their job. Because according to their employer they do. And they are paid for it. They won't do a graceful reload, they won't compress their css and won't escape the user input. But the website will be online, serving customers. This is why on my blog I have articles explaining what's javascript, what's RSS, how to setup the Windows PATH, etc. Because for important tutorials on Python, I can reference those, not assuming people know what I'm talking about.
- struppi 10y ago
  While I agree with almost everything you wrote - I found that original post awesome and there are many great lessons in it - I don't see what this has to do with my comment. Also, I don't get what I seemingly did not realize (mostly helping clients with legacy code on legacy platforms in legacy organizations to improve their quality and teamwork), or why this is disrespectful...
  - sametmax 10y ago
    > For most of my past clients, the skill / output of their programmers was not the bottleneck Of course it was not. If you are antirez, you will mostly work with people on projects which, by nature, will involve talented programmers. > Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output But only a person good enough can do that. This is catch-22 > Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team Yes, but it requires a really good dev to create and execute a plan to progressively enhance it. Instead of doing another from scratch which will also fail. > I have heard of cases where removing the "top programmer" from a team made the whole team more productive Yeah I heard of people stopping vegetables and living fine as well. And "top programmer" <=> "top dev". You can be very good at software and terrible with people. My point is, the entire article is build on assumptions from the "top programmer" perspective. All that goes to the water when your team is composed of: - a senor waiting for retirement - an apprentice fresh out of a community college - a new dad who needs money and hates his job - a legacy spaghetti code project coded by 3 different teams 10 years ago - and no 10x programmer to be found It will work. But say goodbye to best practices, and all the rules Antirez is stating.
DanielBMarkham 10y ago
I used to be a tech lead/PM on teams where we came in as an outsider and delivered code where the organization itself couldn't. Part of that was having great programmers with great habits, sure. But a big part of that was something like "Not letting your broken organization and practices break our delivery speed" Bad org structures and practices pull developers and teams into poorer and poorer practices, like an accretion stream getting sucked into a black hole. The org itself can take a .1 dev and turn them into a .01 dev.

by struppi 10y ago

Ensorceled 10y ago

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.

struppi 10y ago
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...
- Ensorceled 10y ago
  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.
- jansan 10y ago
  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.
simonw 10y ago
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.
- Ensorceled 10y ago
  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.
  - dsacco 10y ago
    And how did you define and measure the "best developers"?
    - watwut 10y ago
      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.
    - Ensorceled 10y ago
      People getting important shit done.
  - icebraining 10y ago
    http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
- LordKano 10y ago
watwut 10y ago
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).

sametmax 10y ago

Come on, Antirez is a x10 programmer, he coded one of the most brillant software of the last decade. It's so well done I use it as an example in my trainings, making people compile it to stop being afraid of building from source because I know it never fails and it's so damn simple. And programmer reading anything on his blog, or anything on HN for that matter, is not an average programmer anyway. The simple fact you are interested in your work singles you out. Guys, you need to come out of your super power bubble and come to work down here. Where people uses PHP, SVN, and don't know what an environment variable is. Where they work for money, not for passion. Where Vi is scary and they pay the licence for Oracle even if their DB has one table. This is the huge majority of the devs : plumbers. I find it disrespectful when people don't realize this, because it means they live a life ignoring a vast majority of dev tool users. Not only those people are numerous, but they create a lot of wealth because they are so many. Don't assume: - devs know the command line - devs know how to setup a server - devs know how to use a package manager - devs know how to version control, unit tests... And above all, if they don't know how to do that, don't assume they can't do their job. Because according to their employer they do. And they are paid for it. They won't do a graceful reload, they won't compress their css and won't escape the user input. But the website will be online, serving customers. This is why on my blog I have articles explaining what's javascript, what's RSS, how to setup the Windows PATH, etc. Because for important tutorials on Python, I can reference those, not assuming people know what I'm talking about.

struppi 10y ago
While I agree with almost everything you wrote - I found that original post awesome and there are many great lessons in it - I don't see what this has to do with my comment. Also, I don't get what I seemingly did not realize (mostly helping clients with legacy code on legacy platforms in legacy organizations to improve their quality and teamwork), or why this is disrespectful...
- sametmax 10y ago
  > For most of my past clients, the skill / output of their programmers was not the bottleneck Of course it was not. If you are antirez, you will mostly work with people on projects which, by nature, will involve talented programmers. > Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output But only a person good enough can do that. This is catch-22 > Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team Yes, but it requires a really good dev to create and execute a plan to progressively enhance it. Instead of doing another from scratch which will also fail. > I have heard of cases where removing the "top programmer" from a team made the whole team more productive Yeah I heard of people stopping vegetables and living fine as well. And "top programmer" <=> "top dev". You can be very good at software and terrible with people. My point is, the entire article is build on assumptions from the "top programmer" perspective. All that goes to the water when your team is composed of: - a senor waiting for retirement - an apprentice fresh out of a community college - a new dad who needs money and hates his job - a legacy spaghetti code project coded by 3 different teams 10 years ago - and no 10x programmer to be found It will work. But say goodbye to best practices, and all the rules Antirez is stating.

DanielBMarkham 10y ago

I used to be a tech lead/PM on teams where we came in as an outsider and delivered code where the organization itself couldn't. Part of that was having great programmers with great habits, sure. But a big part of that was something like "Not letting your broken organization and practices break our delivery speed" Bad org structures and practices pull developers and teams into poorer and poorer practices, like an accretion stream getting sucked into a black hole. The org itself can take a .1 dev and turn them into a .01 dev.