4 ms·

I've never seen a 10x productivity, or even a 2x. I'd like to see one, show me a scrum where one programmer takes 10 stories on the board, and the others just d

by didibus 10y ago

I've never seen a 10x productivity, or even a 2x. I'd like to see one, show me a scrum where one programmer takes 10 stories on the board, and the others just did one, and he successfully finishes all 10, where the team estimated all stories to be of a full scrum length. I doubt this exist. Now, I've seen 10x quality, though sometimes they're a little slower, but never 10x slower. So maybe 1.2x to 3x times slower for something on the order of 5x to 20x quality. That higher quality might pay off long term for the buisness in hard to measure ways, such as faster future extenssion, better customer experience, less work required on bug fixing, etc. If that's what people mean by 10x, I agree, they definitly exist, in fact, compared to the worst there's probably infinite x as people are saying, some programmers can't ever get certain things to work at all. P.S.: Actually, I've seen maybe 2x or 3x productivity on teams with uneven standards, generally lacking code reviews. In those cases though, the 2x or 3x productivity programmers always had similarly lower quality code.

ianbicking 10y ago
10x productivity is fairly common when onboarding people to a project, though it's not quite so obvious because you'll give the new person small bugs or stories. And if someone is simply not productive, there might continue to be a 10x between team members, and the team keeps giving the unproductive person small or non-essential tasks, and not accounting for the support that member receives to finish that work. I've been on both sides of the 10x divide (i.e., the 1x working with a 10x, the 10x working with a 1x). To be clear, these productivity levels were relative to the project, understanding of the project, and the point in the project's lifecycle. There's native talent, but context is just as important. It's not really sustainable to have that productivity difference unless you have a team structure to support it and bring people up – and sometimes I wonder if the team structure is more emotional cover than an actual aggregate productivity boost. It's not sustainable because the 1x developer can't handle the 10x developer's velocity of change. If you are the 1x developer, just at the point when you think you've finally made a valuable improvement, the rug gets pulled out from underneath you yet again because of a change or fix made by someone else. It's demoralizing for everyone, and the 1x developer often becomes the 0x developer (I'm afraid this has also happened to me). It's harder to find unsustainable states because they don't last for long (team breaks up, everyone becomes demoralized, people drift off, etc), which is part of why I think 10x productivity is sometimes treated as a myth.
- watwut 10y ago
  I have seen similar dynamic happen too and would put blame for the situation on the supposed 10x developer. The result is more likely a conswquence of missing communication about changes being done and badly split tasks/responsibilities. Good senior developer should know not to pull rugs from junior. He should not be rewriting juniors work that often. I mean seriously, demotivation happening this way means that the 10x dude should not work in team at all - he should have work individually.
  - ianbicking 10y ago
    People can handle it better or worse, but honestly I think it's just a hard situation with no perfect answers. You're basically proposing adding process to manage the velocity of change. A common situation, for example – some small bug is assigned to a less productive member of the team. The fast developer has to touch that area of the code for some other (often more critical) change. The fast developer sees the bug and just fixes it, or perhaps invalidates the need for that bug fix. Now the less productive member has their work undone. Claiming territory would slow down the fast developer, and also is demotivating for people who are motivated by increased code and product quality and want to bring that attitude to every bit of code they touch. You can run a smallish team with widespread improvements if you are in a situation where turnaround is fast. We're not going to run into too many conflicts if each of us finish our work and get it merged on a daily basis. But then you have that one person who takes a week on a change, and it doesn't go so well. Unless you put them in some codebase ghetto, where changes won't conflict because no one actually cares about the output. How do you manage multiple kinds of vehicles on the road? Speed limits? Minimum speeds? Passing lanes? Semaphores? There's no one right answer, and all the answers are wrong from some perspective.
poikniok 10y ago
"scrum" I found your issue. I don't think 10x developers work in places that do "scrum", as if they are some low skill assembly line worker. You think Jeff Dean does "scrum"?
- phil21 10y ago
  I was also giggling at that as well. Missing the forest through the trees. No, the guy would be doing the entire project. I've worked with "10x" programmers before, exactly one to be exact. The sort of guy who would code to an obviously-wrong spec just to annoy you as a manager, but have the "correct" implementation done and waiting to commit the second you'd amend it. It was an interesting time, and we got a lot done very rapidly. If I had talked about scrum or anything like that'd he'd take one of the other 50 job offers he could get within 24 hours making double - he worked with me because I made his life as easy as possible while trying to give him interesting work. Of course it's not sustainable business-wise for a myriad of reasons. You can't staff a team with those people, but man was he nice to have as programmer #1 in a startup.
- flukus 10y ago
  So 10x programmers don't work anywhere with a somewhat objective performance metric? I don't think that's a coincidence.
  - TeMPOraL 10y ago
    No. Rather, they avoid places which employ procedures designed to get consistent output out of mediocre workers. Such processes naturally exchange flexibility for consistency of results, but lack of flexibility will cripple a 10x programmer.
deleted 10y ago
[deleted]
scruple 10y ago
> I doubt this exist. Of course they exist. We're talking about a talent distribution here and there will be actual human beings who live in the 90th+ percentile who are demonstrably more productive, probably more than "10x", than those in the lower half.
gdulli 10y ago
> I've never seen a 10x productivity, or even a 2x. I'd like to see one, show me a scrum where one programmer takes 10 stories on the board, and the others just did one, and he successfully finishes all 10, where the team estimated all stories to be of a full scrum length. I doubt this exist. I always thought of 10x as a qualitative description, not quantitative. There are certain inflection points where the wrong decision can cause a 10x amount of time to be wasted. One person might have the correct (but counter-intuitive) insight about whether building vs. buying is the right move for a given project. (For example.) Everyone else on the team disagrees and goes with the more obvious choice, which becomes a disaster of a project. So I see 10x as more about wisdom and strategy, not doing 10x the work. It's not always such an large and obvious inflection point, it can be a single algorithm that can be done simply with little code or in just the opposite way. The right approach can reduce the complexity and code by 10x over time as the bugs go down, the maintenance goes down, etc. These things add up, and over time a project under one person's leadership can easily end up with 10x the complexity, bugs, etc. for needless reasons that someone else might have avoided. I have no doubt that the gap in value from the best developer to the average (let alone the worst) can span 10x over time.
watwut 10y ago
This came up first time when programmers had more individual autonomy and responsibility then by the book scrum allows for. The norm used to be that you do module you are responsible for - meaning you can work for few weeks on something biget and alone. At that scope, bad programmer might end up doing mess that is very difficult to finish. If the company does testing and returns bugs to original developer, the developer will be significantly slower.

by didibus 10y ago

ianbicking 10y ago

10x productivity is fairly common when onboarding people to a project, though it's not quite so obvious because you'll give the new person small bugs or stories. And if someone is simply not productive, there might continue to be a 10x between team members, and the team keeps giving the unproductive person small or non-essential tasks, and not accounting for the support that member receives to finish that work. I've been on both sides of the 10x divide (i.e., the 1x working with a 10x, the 10x working with a 1x). To be clear, these productivity levels were relative to the project, understanding of the project, and the point in the project's lifecycle. There's native talent, but context is just as important. It's not really sustainable to have that productivity difference unless you have a team structure to support it and bring people up – and sometimes I wonder if the team structure is more emotional cover than an actual aggregate productivity boost. It's not sustainable because the 1x developer can't handle the 10x developer's velocity of change. If you are the 1x developer, just at the point when you think you've finally made a valuable improvement, the rug gets pulled out from underneath you yet again because of a change or fix made by someone else. It's demoralizing for everyone, and the 1x developer often becomes the 0x developer (I'm afraid this has also happened to me). It's harder to find unsustainable states because they don't last for long (team breaks up, everyone becomes demoralized, people drift off, etc), which is part of why I think 10x productivity is sometimes treated as a myth.

watwut 10y ago
I have seen similar dynamic happen too and would put blame for the situation on the supposed 10x developer. The result is more likely a conswquence of missing communication about changes being done and badly split tasks/responsibilities. Good senior developer should know not to pull rugs from junior. He should not be rewriting juniors work that often. I mean seriously, demotivation happening this way means that the 10x dude should not work in team at all - he should have work individually.
- ianbicking 10y ago
  People can handle it better or worse, but honestly I think it's just a hard situation with no perfect answers. You're basically proposing adding process to manage the velocity of change. A common situation, for example – some small bug is assigned to a less productive member of the team. The fast developer has to touch that area of the code for some other (often more critical) change. The fast developer sees the bug and just fixes it, or perhaps invalidates the need for that bug fix. Now the less productive member has their work undone. Claiming territory would slow down the fast developer, and also is demotivating for people who are motivated by increased code and product quality and want to bring that attitude to every bit of code they touch. You can run a smallish team with widespread improvements if you are in a situation where turnaround is fast. We're not going to run into too many conflicts if each of us finish our work and get it merged on a daily basis. But then you have that one person who takes a week on a change, and it doesn't go so well. Unless you put them in some codebase ghetto, where changes won't conflict because no one actually cares about the output. How do you manage multiple kinds of vehicles on the road? Speed limits? Minimum speeds? Passing lanes? Semaphores? There's no one right answer, and all the answers are wrong from some perspective.

poikniok 10y ago

"scrum" I found your issue. I don't think 10x developers work in places that do "scrum", as if they are some low skill assembly line worker. You think Jeff Dean does "scrum"?

phil21 10y ago
I was also giggling at that as well. Missing the forest through the trees. No, the guy would be doing the entire project. I've worked with "10x" programmers before, exactly one to be exact. The sort of guy who would code to an obviously-wrong spec just to annoy you as a manager, but have the "correct" implementation done and waiting to commit the second you'd amend it. It was an interesting time, and we got a lot done very rapidly. If I had talked about scrum or anything like that'd he'd take one of the other 50 job offers he could get within 24 hours making double - he worked with me because I made his life as easy as possible while trying to give him interesting work. Of course it's not sustainable business-wise for a myriad of reasons. You can't staff a team with those people, but man was he nice to have as programmer #1 in a startup.
flukus 10y ago
So 10x programmers don't work anywhere with a somewhat objective performance metric? I don't think that's a coincidence.
- TeMPOraL 10y ago
  No. Rather, they avoid places which employ procedures designed to get consistent output out of mediocre workers. Such processes naturally exchange flexibility for consistency of results, but lack of flexibility will cripple a 10x programmer.

deleted 10y ago

[deleted]

scruple 10y ago

> I doubt this exist. Of course they exist. We're talking about a talent distribution here and there will be actual human beings who live in the 90th+ percentile who are demonstrably more productive, probably more than "10x", than those in the lower half.

gdulli 10y ago

> I've never seen a 10x productivity, or even a 2x. I'd like to see one, show me a scrum where one programmer takes 10 stories on the board, and the others just did one, and he successfully finishes all 10, where the team estimated all stories to be of a full scrum length. I doubt this exist. I always thought of 10x as a qualitative description, not quantitative. There are certain inflection points where the wrong decision can cause a 10x amount of time to be wasted. One person might have the correct (but counter-intuitive) insight about whether building vs. buying is the right move for a given project. (For example.) Everyone else on the team disagrees and goes with the more obvious choice, which becomes a disaster of a project. So I see 10x as more about wisdom and strategy, not doing 10x the work. It's not always such an large and obvious inflection point, it can be a single algorithm that can be done simply with little code or in just the opposite way. The right approach can reduce the complexity and code by 10x over time as the bugs go down, the maintenance goes down, etc. These things add up, and over time a project under one person's leadership can easily end up with 10x the complexity, bugs, etc. for needless reasons that someone else might have avoided. I have no doubt that the gap in value from the best developer to the average (let alone the worst) can span 10x over time.

watwut 10y ago

This came up first time when programmers had more individual autonomy and responsibility then by the book scrum allows for. The norm used to be that you do module you are responsible for - meaning you can work for few weeks on something biget and alone. At that scope, bad programmer might end up doing mess that is very difficult to finish. If the company does testing and returns bugs to original developer, the developer will be significantly slower.