4 ms·

There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who underst

There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who understand what they are doing. And then... the 100xers like Linus. It's pyramid-shaped. If the author is referring to people who understand what they are doing as "normal" engineers, granted, you can make a great team out of these... but how do you find many of them in the first place without bumping into the others?

alecco 2y ago
Agree. The required abilities multiply rather than add so the right tail extends much further than a normal distribution. The gap between median and top performers is extremely large.
- alecco 2y ago
  Please read that the right way. Deliberate practice compounds exponentially. Those extra hours refactoring, contributing to OSS, or mastering systems design create 10x impact through learned architectural intuition that median devs never develop. Your new skills will go a long way.
- datadrivenangel 2y ago
  The 10x programmer is based on research cited in the Mythical Man Month, and there the most productive programmer was 10 times more productive than the least productive, as far as time taken to complete a coding task. The most productive were ~3x faster than the mean/median programmer.
atoav 2y ago
To start with, there are engineers who deserve the title engineer. You are probably better of to hire a former civil/electrical engineer that can fizz-buzz than someone that can just fizz-buzz. Coding and productivity are one thing, but engineering in the end is a lot about having a certain awareness of the impact your technological choices have on a project both in the short and long term. I'd rather take someone who has this awareness, than someone who hasn't, even if the person in the latter category would be slightly better at coding.
arkh 2y ago
You also have force multipliers. Which can be some managers: people whose presence on a project will make decent software engineers produce like a 2x one.
Juliate 2y ago
Not of that opinion. I met great engineers or developers who won't even care to answer a fizzbuzz-type question. I met terrible ones who had top technical and math capabilities but little agency at pointing what is relevant or not in their work. Even considering it's pyramid-shaped is excluding all the externalities that make one person thrive in some contexts, and just flat or negative in others. Take a top performer, if he's not in the right position at the right time, nothing will happen. Conversely, someone not so good, but being in the right place at the right moment may nudge things in the right direction. That's exactly around what I understand the OP develops in her article: engineering, building is a work of teams, not individuals. In a team, people come and go, roles are different, shift with time and progress. "Terrible" people become "excellent" and the other way around, that's life. Perfect performance all the time isn't even what we require of machines, because then they (or systems they relate to) break faster. Why would one have the same expectations with people?
- rachofsunshine 2y ago
  "There exist exceptions to a trend" does not mean the trend is not a valid proxy (see [1]), and "refuses to do fizzbuzz" is different from "can't do fizzbuzz". I run a technical recruiting company, and we ask candidates a question like [2] on our interview (EDIT: we ask other stuff too, this is only part of it). It's not exactly fizzbuzz, but it's really not far beyond it. A candidate we interviewed just a couple days ago took that problem and couldn't even complete the first step. This is the equivalent of asking someone applying for a job as a statistician what the distribution of the sum of two normals is, or asking someone applying for a job as a con-law lawyer what the fifth amendment is, and having them go totally blank. Is it conceivable that they were just having a rough day and their brain hiccuped really badly? Sure, I suppose. If we did ten thousand interviews, we'd probably have at least one person who is objectively great perform that way. But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000. ----- [1] https://news.ycombinator.com/item?id=43006330 https://news.ycombinator.com/item?id=43006330 [2] https://www.otherbranch.com/shared/practice-coding-problem https://www.otherbranch.com/shared/practice-coding-problem
interludead 2y ago
There's a huge middle ground between "can't FizzBuzz" and "100x Linus-level genius," and that middle is where most functioning engineering teams live
- gatinsama 2y ago
  Yes, but it's way more on the can't fizzbuzz side. Our view is skewed because of the people we work with. If you have an extreme Pareto distribution, talking about "normal" is not helpful.

alecco 2y ago

Agree. The required abilities multiply rather than add so the right tail extends much further than a normal distribution. The gap between median and top performers is extremely large.

alecco 2y ago
Please read that the right way. Deliberate practice compounds exponentially. Those extra hours refactoring, contributing to OSS, or mastering systems design create 10x impact through learned architectural intuition that median devs never develop. Your new skills will go a long way.
datadrivenangel 2y ago
The 10x programmer is based on research cited in the Mythical Man Month, and there the most productive programmer was 10 times more productive than the least productive, as far as time taken to complete a coding task. The most productive were ~3x faster than the mean/median programmer.

atoav 2y ago

To start with, there are engineers who deserve the title engineer. You are probably better of to hire a former civil/electrical engineer that can fizz-buzz than someone that can just fizz-buzz. Coding and productivity are one thing, but engineering in the end is a lot about having a certain awareness of the impact your technological choices have on a project both in the short and long term. I'd rather take someone who has this awareness, than someone who hasn't, even if the person in the latter category would be slightly better at coding.

arkh 2y ago

You also have force multipliers. Which can be some managers: people whose presence on a project will make decent software engineers produce like a 2x one.

Juliate 2y ago

Not of that opinion. I met great engineers or developers who won't even care to answer a fizzbuzz-type question. I met terrible ones who had top technical and math capabilities but little agency at pointing what is relevant or not in their work. Even considering it's pyramid-shaped is excluding all the externalities that make one person thrive in some contexts, and just flat or negative in others. Take a top performer, if he's not in the right position at the right time, nothing will happen. Conversely, someone not so good, but being in the right place at the right moment may nudge things in the right direction. That's exactly around what I understand the OP develops in her article: engineering, building is a work of teams, not individuals. In a team, people come and go, roles are different, shift with time and progress. "Terrible" people become "excellent" and the other way around, that's life. Perfect performance all the time isn't even what we require of machines, because then they (or systems they relate to) break faster. Why would one have the same expectations with people?

rachofsunshine 2y ago
"There exist exceptions to a trend" does not mean the trend is not a valid proxy (see [1]), and "refuses to do fizzbuzz" is different from "can't do fizzbuzz". I run a technical recruiting company, and we ask candidates a question like [2] on our interview (EDIT: we ask other stuff too, this is only part of it). It's not exactly fizzbuzz, but it's really not far beyond it. A candidate we interviewed just a couple days ago took that problem and couldn't even complete the first step. This is the equivalent of asking someone applying for a job as a statistician what the distribution of the sum of two normals is, or asking someone applying for a job as a con-law lawyer what the fifth amendment is, and having them go totally blank. Is it conceivable that they were just having a rough day and their brain hiccuped really badly? Sure, I suppose. If we did ten thousand interviews, we'd probably have at least one person who is objectively great perform that way. But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000. ----- [1] https://news.ycombinator.com/item?id=43006330 https://news.ycombinator.com/item?id=43006330 [2] https://www.otherbranch.com/shared/practice-coding-problem https://www.otherbranch.com/shared/practice-coding-problem

interludead 2y ago

There's a huge middle ground between "can't FizzBuzz" and "100x Linus-level genius," and that middle is where most functioning engineering teams live

gatinsama 2y ago
Yes, but it's way more on the can't fizzbuzz side. Our view is skewed because of the people we work with. If you have an extreme Pareto distribution, talking about "normal" is not helpful.