8 ms·

High Performance Individuals and Teams

92 points by pablasso 6y ago

troughway 6y ago
I’ve been fortunate in my career thus far, since I was about 14 or so, to have always been in the company of at least one “10x”’er on each of my teams, as the cliche goes. They’re dispersed through various companies nowadays - Stripe, Twitch, Google, FB, Discord, etc etc. But it was interesting and beneficial for me to work alongside them if only because I had decent role models to follow. This article first puts up a straw man and then switches gears halfway into a different subject. See if you can spot it. There is no exaggeration. Some people are just far more in tune with the mental models required to do good software work at both a micro and macro level, that any time I see someone trying to play it down I have to ask if these individuals have worked with one of these precocious talented folks. I also sometimes struggle to understand why anyone would write an article like this. You obviously want to hire the best you can for the best price you can. Anything else is a silly coping mechanism that you can’t face with honesty. I want to read an article that’s straightforward about how much good work 10x’ers can do and how influential they can be for rest of the team. But this isn’t an article anyone would bother writing because they’re too busy making money to have dick measuring competitions on an online news board.
- logicslave 6y ago
  I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Sometimes the software they produce is absolutely stunning.
  - naniwaduni 6y ago
    Or, alternatively, the 0.1x engineer and the -10x engineer. (Or worse, the -10x PM.)
    - nullsense 6y ago
      Yeah. Engineers fall on a distribution. It's just that simple.
      - gwright 6y ago
        OK, now if it were only simple to figure out where on that distribution a particular engineer falls during the limited time of the hiring process.
    - totemandtoken 6y ago
      As the joke goes, "There does exist a 10x engineer, but unfortunately it's in binary"
  - BeetleB 6y ago
    > I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Food for thought: The interpretation of a 10x engineer is not consistent. Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes". That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, etc. If you don't do these well, much of your brilliant engineering gains will go to waste. A brilliant engineer may be harder to replace than the average, but he/she is not a 10x engineer. Perhaps a 2x.
    - JimDabell 6y ago
      > Can I replace 10 of my average engineers with this one person? The answer is never "yes". That’s because the “10x” is an order of magnitude difference between the best and the worst, not the average. https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/ https://www.construx.com/blog/productivity-variations-among-...
      - BeetleB 6y ago
        Fair enough. In that case, I would expect a multiplier much larger than 10x. :-) Definitely encountered folks who fail on FizzBuzz and similar problems.
      - username90 6y ago
        Note that the worst doesn't even finish so the difference is infinite. 10x is the difference between the fastest and slowest of those who could complete the project.
    - dragonwriter 6y ago
      > Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes". Well, yeah, people aren't interchangeable cogs. A person that is capable of delivering 10× value per unit of working time when properly employed probably isn't a drop in replacement for 10 1× developers. And managers thinking of people as interchangeable cogs where productivity multiples work by simple substitutions that way are great at getting ~sqrt(N)× (or less) output and quick burnout from N× (N > 1) developers. > That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, etc. Yeah, and all of those things are things a developer can be better at than average, not just technical design and coding. Sure, there's some high productivity developed that are average or worse at some but much better at one area, there's also high productivity developers that are better than average across the board.
- fctorial 6y ago
  Can john carmack build 10 crud apps in a week?
  - username90 6y ago
    Pretty sure he could if he got to practice writing crud apps for a month beforehand and the apps were no more complicated than what a mediocre engineer can write in a week.
    - Viliam1234 6y ago
      Also, one engineer making 10 crud apps would probably share a lot of code between the apps. Which would allow him to make the new ones even faster. And the result would be easier to maintain. If you instead hire 10 engineers to write 1 app each, you often end up with 10 apps using 8 different frameworks in 3 different languages. And then you will need 10 engineers to maintain them.
coderintherye 6y ago
"If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god." This is hard for many to grasp, but if you get the opportunity to lead enough teams it will become clear. And it makes sense, if you think about it. An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure their code in order to maintain full control over it. It's job security and furthermore if it's a valuable piece of the product then it can keep praise and rewards centered on you. We should also not be quick to blame the individual for perpetuating this, the right incentives need to be in place to reward both team progress and individual progress.
- harrisonjackson 6y ago
  > We should also not be quick to blame the individual for perpetuating this This part at least, I agree with. Whenever I see code like this it is a symptom of a larger product development issue. - unreasonable deadlines - overpromising to external clients - no coding standards (enforced by linter and code review) - no automated testing - no code review process - using new languages/technologies without first gaining some experience about best practices Early on, a startup definitely needs engineers that are going to work autonomously, cut corners as needed, not be a perfectionist, etc. The technical cofounder/CTO/team leader should still be setting up a culture of high quality code. Coding styles and some automated testing make it easier to move quickly and ramp up new team members or for old team members to circle back to old code.
- Arelius 6y ago
  > An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure their code in order to maintain full control over it. That's fair, but I've also seen an orthogonal effect happen maybe more often where an engineer structures code just naturally in a way that fits them well, but is poorly understood by others. Not due to the incentives of maintaining control or job security. But simply because the engineer wasn't talented at making good code for other humans, and there were very few incentives to write code good for other people, at least early on in the design.
usefulcat 6y ago
> Even more important than finding great engineers is to avoid bad ones. After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years. My takeaway from this is that at even with ~18 years of experience, my former self would probably not have appreciated the importance of this advice, as I had rarely or never encountered such a person thus far.
- tjpnz 6y ago
  What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? If it's the former I've perhaps encountered only one in the last ten years. If it's the latter it's almost every month.
  - jachee 6y ago
    Considering the Dunning-Krueger effect, my Imposter Syndrome is sure that I must either be a bad engineer, and that it's just a matter of time before I mess up in a situation because I incorrectly evaluate my skill level at evaluating my skill level... etc. or that I'm a decent engineer. I've been trying to avoid that meta-evaluation spiral for years by semi-regularly checking with third parties to confirm that I'm generally the person I believe I am. So far, so good. Edit: Almost forgot: The whole point of this introspection is to point out that the self both is and isn't a decent guidepost for evaluating others.
  - usefulcat 6y ago
    > What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? Those categories aren't necessarily disjoint. There can be many aspects, many of which are described in the paper. But in my experience, one of the more pernicious combinations is the sincere belief that one already knows nearly everything worth knowing, coupled with a complete lack of curiosity (or perhaps it was merely utter laziness). When that happens, a person stagnates. In the case I saw, a person with decades of experience was effectively performing only marginally better than someone who had just begun their career. The major difference being that a person who has just started is often well aware that they have a lot to learn. Or even if they're not, if they're curious then there's at least a good chance that they will figure that out in time.
leftyted 6y ago
Whether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist. I know a few in that category. And it really amounts to the same thing.
- JimDabell 6y ago
  > Whether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist. Not in this context. The term “10x programmer” comes from an observation that there is a factor of ten variation between the best and the worst programmers. So the worst programmers in this context are 1x, and 1/10th is meaningless. People hear “10x” and assume it’s ten times the average, but that’s not the case. More information here: https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/ https://www.construx.com/blog/productivity-variations-among-...
  - stingraycharles 6y ago
    I think the post of the parent is a bit tongue-in-cheek; I read it mostly as “I don’t know whether there are a few developers that are significantly better than the rest, but I do know there are a few developers that are significantly worse than the rest”. It’s effectively the same thing, but from a different perspective.
- carlmr 6y ago
  I think the multipliers also conceal another issue. A lot of programmers have a net negative impact on your code base. They may be "productive" in the sense that they produce a lot of code, but then that code is riddled with bugs that drag down the whole team's velocity. If you're 10x of a negative impact then you just produce bugs faster.
  - kqr 6y ago
    It doesn't take broken code to have a net negative impact. Any code at all is liability, so if you're writing code, it better be worth it. Figuring out what produces value is surprisingly hard, so I would bet the majority of code being written has a net negative impact. And then don't get me started on marginal profit. Producing some value is a lot easier than producing marginal value that outweighs marginal costs. Now we're talking a smallish fraction of the code being written.
AlchemistCamp 6y ago
> Even more important than finding great engineers is to avoid bad ones. I don't know how many Jeff Deans and John Carmacks the OP would turn away in order to avoid a bad engineer on the team, but for me the answer is zero.
- username90 6y ago
  If you do hire them but your process can't tell the difference between them and the bad engineer they work with they will get frustrated and quit soon. The most important part to keep good engineers is to ensure they don't have to work alongside bad engineers.
  - AlchemistCamp 6y ago
    I can't imagine a situation where I couldn't tell the difference between either of them and a bad engineer. I'd either be pair programming with them and learning a lot or be pairing with a "bad engineer" and suffering.
    - Viliam1234 6y ago
      Sometimes people making the decision about hiring are not programmers themselves, or happen to be the bad engineers. In both cases, the difference between a good and bad engineer can be invisible for them.
TeeMassive 6y ago
> If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god. I have actually experienced this. Huge code base, 25+ years, oldest copyright notice goes as far back to 1995. Worse of all is that refactoring would always need middle management's approval, and the "tech leads" would never delegate jobs and would always spew out code like crazy while the rest of the team was slowed due to their mess. I'm glad I quit.
juancn 6y ago
I've worked with 10x-ers. They do exist. In my experience they're extraordinary people in many, many aspects. More than anyone has a right to. Besides the god-like ability to solve problems, they were amazing mentors, and clear communicators focused on what's right for the team at the time. They were universally liked and working with them makes you a better professional. Software is a a team sport, successes is hard to come by on your own.
- juancn 6y ago
  I also worked with 0.5x-ers. Whose presence alone would drop value in half.
- Viliam1234 6y ago
  Some people make it a false dilemma: either there are "mythical" 10x developers, or it is about teamwork. Then they prove the teamwork is important... and therefore 10x developers do not really exist! But in fact, there are people who are 10x developers and are great team players. And there are also people with great technical skills, who are completely toxic. And there are also people with mediocre technical skills who believe themselves to be gods, and for some reason management seems to believe them. All of these are real, and I have met them. For good cooperation, both the 10x developer and the rest of the team need to be good team players. Because some people are unable to teach, but also some people are unable to learn. Some people are condescending to those with less experience, but also some people are hostile to those with more experience. If the team works well together, the 10x developer can set the project architecture right, teach other team members to follow some good principles, and then all together do seemingly miracles.

92 points by pablasso 6y ago

I’ve been fortunate in my career thus far, since I was about 14 or so, to have always been in the company of at least one “10x”’er on each of my teams, as the cliche goes. They’re dispersed through various companies nowadays - Stripe, Twitch, Google, FB, Discord, etc etc. But it was interesting and beneficial for me to work alongside them if only because I had decent role models to follow. This article first puts up a straw man and then switches gears halfway into a different subject. See if you can spot it. There is no exaggeration. Some people are just far more in tune with the mental models required to do good software work at both a micro and macro level, that any time I see someone trying to play it down I have to ask if these individuals have worked with one of these precocious talented folks. I also sometimes struggle to understand why anyone would write an article like this. You obviously want to hire the best you can for the best price you can. Anything else is a silly coping mechanism that you can’t face with honesty. I want to read an article that’s straightforward about how much good work 10x’ers can do and how influential they can be for rest of the team. But this isn’t an article anyone would bother writing because they’re too busy making money to have dick measuring competitions on an online news board.

logicslave 6y ago
I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Sometimes the software they produce is absolutely stunning.
- naniwaduni 6y ago
  Or, alternatively, the 0.1x engineer and the -10x engineer. (Or worse, the -10x PM.)
  - nullsense 6y ago
    Yeah. Engineers fall on a distribution. It's just that simple.
    - gwright 6y ago
      OK, now if it were only simple to figure out where on that distribution a particular engineer falls during the limited time of the hiring process.
  - totemandtoken 6y ago
    As the joke goes, "There does exist a 10x engineer, but unfortunately it's in binary"
- BeetleB 6y ago
  > I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Food for thought: The interpretation of a 10x engineer is not consistent. Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes". That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, etc. If you don't do these well, much of your brilliant engineering gains will go to waste. A brilliant engineer may be harder to replace than the average, but he/she is not a 10x engineer. Perhaps a 2x.
  - JimDabell 6y ago
    > Can I replace 10 of my average engineers with this one person? The answer is never "yes". That’s because the “10x” is an order of magnitude difference between the best and the worst, not the average. https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/ https://www.construx.com/blog/productivity-variations-among-...
    - BeetleB 6y ago
      Fair enough. In that case, I would expect a multiplier much larger than 10x. :-) Definitely encountered folks who fail on FizzBuzz and similar problems.
    - username90 6y ago
      Note that the worst doesn't even finish so the difference is infinite. 10x is the difference between the fastest and slowest of those who could complete the project.
  - dragonwriter 6y ago
    > Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes". Well, yeah, people aren't interchangeable cogs. A person that is capable of delivering 10× value per unit of working time when properly employed probably isn't a drop in replacement for 10 1× developers. And managers thinking of people as interchangeable cogs where productivity multiples work by simple substitutions that way are great at getting ~sqrt(N)× (or less) output and quick burnout from N× (N > 1) developers. > That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, etc. Yeah, and all of those things are things a developer can be better at than average, not just technical design and coding. Sure, there's some high productivity developed that are average or worse at some but much better at one area, there's also high productivity developers that are better than average across the board.
fctorial 6y ago
Can john carmack build 10 crud apps in a week?
- username90 6y ago
  Pretty sure he could if he got to practice writing crud apps for a month beforehand and the apps were no more complicated than what a mediocre engineer can write in a week.
  - Viliam1234 6y ago
    Also, one engineer making 10 crud apps would probably share a lot of code between the apps. Which would allow him to make the new ones even faster. And the result would be easier to maintain. If you instead hire 10 engineers to write 1 app each, you often end up with 10 apps using 8 different frameworks in 3 different languages. And then you will need 10 engineers to maintain them.

coderintherye 6y ago

"If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god." This is hard for many to grasp, but if you get the opportunity to lead enough teams it will become clear. And it makes sense, if you think about it. An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure their code in order to maintain full control over it. It's job security and furthermore if it's a valuable piece of the product then it can keep praise and rewards centered on you. We should also not be quick to blame the individual for perpetuating this, the right incentives need to be in place to reward both team progress and individual progress.

harrisonjackson 6y ago
> We should also not be quick to blame the individual for perpetuating this This part at least, I agree with. Whenever I see code like this it is a symptom of a larger product development issue. - unreasonable deadlines - overpromising to external clients - no coding standards (enforced by linter and code review) - no automated testing - no code review process - using new languages/technologies without first gaining some experience about best practices Early on, a startup definitely needs engineers that are going to work autonomously, cut corners as needed, not be a perfectionist, etc. The technical cofounder/CTO/team leader should still be setting up a culture of high quality code. Coding styles and some automated testing make it easier to move quickly and ramp up new team members or for old team members to circle back to old code.
Arelius 6y ago
> An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure their code in order to maintain full control over it. That's fair, but I've also seen an orthogonal effect happen maybe more often where an engineer structures code just naturally in a way that fits them well, but is poorly understood by others. Not due to the incentives of maintaining control or job security. But simply because the engineer wasn't talented at making good code for other humans, and there were very few incentives to write code good for other people, at least early on in the design.

usefulcat 6y ago

> Even more important than finding great engineers is to avoid bad ones. After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years. My takeaway from this is that at even with ~18 years of experience, my former self would probably not have appreciated the importance of this advice, as I had rarely or never encountered such a person thus far.

tjpnz 6y ago
What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? If it's the former I've perhaps encountered only one in the last ten years. If it's the latter it's almost every month.
- jachee 6y ago
  Considering the Dunning-Krueger effect, my Imposter Syndrome is sure that I must either be a bad engineer, and that it's just a matter of time before I mess up in a situation because I incorrectly evaluate my skill level at evaluating my skill level... etc. or that I'm a decent engineer. I've been trying to avoid that meta-evaluation spiral for years by semi-regularly checking with third parties to confirm that I'm generally the person I believe I am. So far, so good. Edit: Almost forgot: The whole point of this introspection is to point out that the self both is and isn't a decent guidepost for evaluating others.
- usefulcat 6y ago
  > What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? Those categories aren't necessarily disjoint. There can be many aspects, many of which are described in the paper. But in my experience, one of the more pernicious combinations is the sincere belief that one already knows nearly everything worth knowing, coupled with a complete lack of curiosity (or perhaps it was merely utter laziness). When that happens, a person stagnates. In the case I saw, a person with decades of experience was effectively performing only marginally better than someone who had just begun their career. The major difference being that a person who has just started is often well aware that they have a lot to learn. Or even if they're not, if they're curious then there's at least a good chance that they will figure that out in time.

leftyted 6y ago

Whether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist. I know a few in that category. And it really amounts to the same thing.

JimDabell 6y ago
> Whether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist. Not in this context. The term “10x programmer” comes from an observation that there is a factor of ten variation between the best and the worst programmers. So the worst programmers in this context are 1x, and 1/10th is meaningless. People hear “10x” and assume it’s ten times the average, but that’s not the case. More information here: https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/ https://www.construx.com/blog/productivity-variations-among-...
- stingraycharles 6y ago
  I think the post of the parent is a bit tongue-in-cheek; I read it mostly as “I don’t know whether there are a few developers that are significantly better than the rest, but I do know there are a few developers that are significantly worse than the rest”. It’s effectively the same thing, but from a different perspective.
carlmr 6y ago
I think the multipliers also conceal another issue. A lot of programmers have a net negative impact on your code base. They may be "productive" in the sense that they produce a lot of code, but then that code is riddled with bugs that drag down the whole team's velocity. If you're 10x of a negative impact then you just produce bugs faster.
- kqr 6y ago
  It doesn't take broken code to have a net negative impact. Any code at all is liability, so if you're writing code, it better be worth it. Figuring out what produces value is surprisingly hard, so I would bet the majority of code being written has a net negative impact. And then don't get me started on marginal profit. Producing some value is a lot easier than producing marginal value that outweighs marginal costs. Now we're talking a smallish fraction of the code being written.

AlchemistCamp 6y ago

> Even more important than finding great engineers is to avoid bad ones. I don't know how many Jeff Deans and John Carmacks the OP would turn away in order to avoid a bad engineer on the team, but for me the answer is zero.

username90 6y ago
If you do hire them but your process can't tell the difference between them and the bad engineer they work with they will get frustrated and quit soon. The most important part to keep good engineers is to ensure they don't have to work alongside bad engineers.
- AlchemistCamp 6y ago
  I can't imagine a situation where I couldn't tell the difference between either of them and a bad engineer. I'd either be pair programming with them and learning a lot or be pairing with a "bad engineer" and suffering.
  - Viliam1234 6y ago
    Sometimes people making the decision about hiring are not programmers themselves, or happen to be the bad engineers. In both cases, the difference between a good and bad engineer can be invisible for them.

TeeMassive 6y ago

> If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god. I have actually experienced this. Huge code base, 25+ years, oldest copyright notice goes as far back to 1995. Worse of all is that refactoring would always need middle management's approval, and the "tech leads" would never delegate jobs and would always spew out code like crazy while the rest of the team was slowed due to their mess. I'm glad I quit.

juancn 6y ago

I've worked with 10x-ers. They do exist. In my experience they're extraordinary people in many, many aspects. More than anyone has a right to. Besides the god-like ability to solve problems, they were amazing mentors, and clear communicators focused on what's right for the team at the time. They were universally liked and working with them makes you a better professional. Software is a a team sport, successes is hard to come by on your own.

juancn 6y ago
I also worked with 0.5x-ers. Whose presence alone would drop value in half.
Viliam1234 6y ago
Some people make it a false dilemma: either there are "mythical" 10x developers, or it is about teamwork. Then they prove the teamwork is important... and therefore 10x developers do not really exist! But in fact, there are people who are 10x developers and are great team players. And there are also people with great technical skills, who are completely toxic. And there are also people with mediocre technical skills who believe themselves to be gods, and for some reason management seems to believe them. All of these are real, and I have met them. For good cooperation, both the 10x developer and the rest of the team need to be good team players. Because some people are unable to teach, but also some people are unable to learn. Some people are condescending to those with less experience, but also some people are hostile to those with more experience. If the team works well together, the 10x developer can set the project architecture right, teach other team members to follow some good principles, and then all together do seemingly miracles.