The main premise of the post is this:
> The best engineering organizations are the ones where normal engineers can do great work
But this is entirely compatible with the notion of superstars pulling the whole team forward
“Normal” engineers are the key to great teams
331–340 of 543 posts
Re: “Normal” engineers are the key to great teams
#332There 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…
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.
Re: “Normal” engineers are the key to great teams
#333Earlier quoted context omitted.
>These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. Didn't we pass the rubicon on that in the early 2010s? I personally don't feel that its "like" finance but that its the exact same behaviors from the exact same set of people. Once tech stopped being a bunch of nerds in a basement and started being a source of wealth and power, it…
Oh stop narrating like nerds in a basement are cuddly lovable bunch. Amount of toxic behavior in nerdy groups is just as high as finance. Every single one just thinks how smart he is and how to one up the other. Technical interviews were always bad even before 2010 as there was loads of gatekeeping anyway.
Yup, this idea that we're in a unique industry or that our industry is any different to any other career path is very toxic.
Accountants have the same bullshit memes we do.
Re: “Normal” engineers are the key to great teams
#334With engineers (in software and engineering) i found out that a lot of people are there just for the money. Those have no passion and will never be great regardless of the skill.
Then there are also different individual skills (like magnus carlsen is more skilled in chess than me) that are influcened by practice and talent.
Also for a lot of problems experience might be more helpful than intelligence so you dont need to be einstein to engineer a dishwasher (probably).
Re: “Normal” engineers are the key to great teams
#335There 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…
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?
Re: “Normal” engineers are the key to great teams
#336I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…
> Individuals ship software not teams
This is true at time T. But over time (can be as short as a matter of weeks), it is not anymore. Team work, interactions, support, resiliency takes over, in a good way.
And that's a good thing, because that's how you build relevance for your work.
If your take on managing your team is fighting complacency and mediocrity, maybe it's the hiring/training/managing process that ought to be reviewed _first_.
Re: “Normal” engineers are the key to great teams
#337I think productivity isn't just about speed; it's about long-term sustainability, resilience... And it seems for many businesses it's hard to understand
Re: “Normal” engineers are the key to great teams
#338Earlier quoted context omitted.
> I bet a lot of people 10-15 years older than you would say the same thing - except they'd say it about you and your generation. And they’d probably be right! I remember the grognards giving me shit about memory management and me giving it right back by explaining that what they considered a large chunk of memory would be worth pennys next year because of Moore’s law and I wasn’t going to waste time considering some…
As a fun anecdote I think this same rationale - ”next years hardware is so much better” - is why so many desktop softwares 90’s->00’s became slow - ”meh you don’t have to care about performance, next year’s cpu is going to be so much faster anyway”. Then suddenly single threaded speedups didn’t happen anymore (and people realized even though cpu speeds had grown, it was not directly related to Moore’s law). Ofc your…
Seeing this multiple times in a day for multiple, articulable reasons in the mid 2010s if my memory doesnt fail me
>FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory > 1: node::Abort() [/usr/bin/node]
Is what made me decide it might finally be worth the time to actually learn how memory worked
Re: “Normal” engineers are the key to great teams
#339There 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…
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
Re: “Normal” engineers are the key to great teams
#340I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…
The "two people carrying the team" dynamic does happen, but that's often a sign of bad management, not some immutable law of engineering