Strong engineers have a high degree of plasticity but fail suddenly. Weak engineers can be made strong by arranging them in groups but you need to watch your points of tension and compression, using tools like finite element analysis.
Testing strong engineers to destruction in a lab should only be carried out by competent materials scientists.
Have you ever seen a group of individually strong engineers accomplish nothing because they spent all thier time fighting and/or building technically correct stuff that has no business use case? I sure have.
And likewise, I have seen technically weak engineers who are capable of getting along with others deliver great output with high business value.
Imho, the fact the author calls some engineers "0's" is the type of egalitarian douchenozzelry that I have seen bring entire teams to a halt, and why I think the author comes off as a blow hard. If you think any person is a zero, the more likely truth is you don't know how to properly asses a person's skills and put them to use where they fit - and that's an eng leadership failure, not an ic failure.
I hate bullshit like this. Practice makes perfect. Put time into something, and you’ll get good at it. That’s that, don’t jerk yourself off and think you are stronger and others are weaker.
- Some people are at this ALL day, that’s why they are good and getting better.
- Some people take DRUGS to do this all day.
- Do not doubt the sheer hours it takes to get good.
- Some engineers get worse because they practice the wrong things (whatever it is, could be a bad coding practice, it could be bike shedding, etc)
- Practice is a vector, it has magnitude and direction. Stop marveling at the final product of practice and marvel at practice itself. It’s powerful in either direction, it can lift you or keep you stuck in a Sisyphean loop.
Practice does not make perfect. I know people who sing every single day, yet after decades of practice it's out of tune.
Practice just means you'll get better at doing what you're doing. If what you're doing is wrong or lame then you'll just use even fewer brain cycles to do the wrong thing.
Improvement only comes when someone specifically seeks out to change the way they're doing things.
Or I can be trained to meet a standard also - regardless if I want to improve or not, if I do not follow my training and checklists, I will eventually lose my job. I will deliver perfection and leave work on time or else...
To sing well, one must first know when they're not singing well, so "singing every day" is not the key, singing better over time is the key, or the practice is not worth anything, except, perhaps, for volume :-)
Assuming this comes from the Vivek thing on twitter, the distinction is rather that the visa proces let’s companies do strong coercion against visa holders.
If they don’t sacrifice their life for their job they get deported after all.
It is funny that this article is what we ended up from that beginning tho.
Basically "groypers" and literal neo-nazis are whining about Indians on X. Instead of ignoring them people like Elon Musk and Vivek are going full-defensive mode about the current dysfunctional H1B visa system.
Honestly it seems like the American Right have convinced themselves that Xitter is now real life and that they have to engage even the most stupid neo-nazi trolls.
When someone's head is up their a_s, one shouldn't listen to their opinion of how the world smells. And believe me when I say that Vivek and ElMusk are out of their frickin minds. Of course, that isn't putting a dent in their meaningless overconfidence, but Dunning-Kruger is, as always, instructive.
I like to think of different engineer tiers as pricing tiers in SaaS: "everything in the previous tier + higher limits + new stuff you can only get in this tier".
Ok wouldn't have chosen the terms, but yeah there are some devs who can jump in and solve problems and others who seem to not understand the company business model after months or years of immersion. Those that get things done and those that seem to not even know what needs doing. Etc.
So what about the -10x engineers? One trick that gets what the article calls 'weak' engineers to senior is procrastinating solving the business problems (they are weak engineers ergo they _can't_ solve the business's problems) and focusing instead on the toil of process, which they tend to inflate and extend. And this checks the boxes that managers are using to evaluate engineers and promote them.
I've seen weak senior engineers completely tank whole dev orgs by overarchitecting the CI and adding gazillions of brittle tests and completely taking away any chance of the strong engineers ever getting solutions to the business's problems into production!
> I've seen weak senior engineers completely tank whole dev orgs by overarchitecting the CI and completely taking away any chance of the strong engineers ever getting solutions to the business's problems into production!
Wow I thought I was the only one who saw such a thing. Glad I'm not alone
toil of process, which they tend to inflate and extend.
I don’t know what to say about this. I remember this one dev who was super obsessed about code coverage (like, the actual coverage number - this detail is important). I don’t think this person even gave a shit about the tests, it just has to tick off that 90%+ test coverage metric which he was obsessed with, and the code needed to look exhaustive. I know this because that’s what his tests were exactly like.
The tests were like the lamest tests ever, but they appeared comprehensive and exhaustive. It never really added much to the app, and it was just insane busy work.
How do you tell a business this an absolute waste of money? You can’t because culturally code coverage is good.
So I don’t even know who to blame here. This kind of shit happens constantly because we built some kinda tech culture that incentivizes it. We as an industry seem to have a really hard to time telling a 20 something (who may or may not be jacked up on stimulants) to settle the fuck down.
Code coverage should be easy. if it's costing time, you're doing it wrong. if you're trying to apply it to an old project that did not use code coverage from the start: This is one way to do it wrong. you couldn't hold a gun to my head and make me do that. you can have a little bit of code coverage in this case, but not 85% - no. The moment it proves that it will be costing more time than it saves is the moment you can count me out.
No no, let me be clear. It’s a business, my natural instincts were “this is a waste of money even if it doesn’t take much work”. It’s a business! It’s valid feedback. This is not true for all businesses, but for our business it was true.
How do you tell many many many developers that the reason they shouldn’t focus on certain things is because it’s a waste of money?
This not a topic that comes up a lot because most developers are divorced from the bottom line.
Anyway, this topic can head off in all kinds of directions.
well you said it was "insane busy work" and I do not see how that is possible unless applied incorrectly. 90% plus coverage is some smoke ,for example. I don't use code coverage on most of my projects though because the teams are just one or two people, and the projects only live a few years without ever being updated. The teams would have to be bigger the updates more frequent, and the project life span longer.
I thought of a good way to break down why obsession with code coverage is poor.
The same program can be represented in many different ways. And code is data.
We can take the program and compile it to a byte code. We then represent the byte code as an array of bytes which is bundled with the virtual machine to make the working program.
The byte code uses every instruction of the virtual machine. And so, wee, we have 100% code coverage.
Of course not 100% of the byte code array is executed by the VM, but pay no attention to that. Code coverage is about code, not data!
The only coverage that matters is the coverage of the state space: hitting all the cases that can occur. There isn't a nice one-to-one correspondence between control flow paths and cases. A routine which adds to unsigned 16-bit integers has 65536 x 65536 cases, but nowhere near that many paths through its control graph.
> [...] I remember this one dev who was super obsessed about code coverage [...]
Oh, you are lucky. Where I work that's the person who defines how to test and which tools to use. Look at the code, create tests to paint everything green. Whether the code actually works does not matter. I don't think these tests have ever caught any kind of bug. That isn't even their purpose.
> So I don’t even know who to blame here.
Money. If tests can be written without understanding what the code is supposed to do, they can be written by people who do not understand. Which appears to be the cheapest way to get passing tests. Not to find any bugs, but that's not what the process requires.
> How do you tell a business this an absolute waste of money? You can’t because culturally code coverage is good.
Theoretically yes, but practically not as much as it should be, because we've chosen a bad way to represent the metric. It should be an absolute number and flipped - we don't care about the covered lines, we care about the uncovered lines. Like instead of "90% of the code is covered by tests" it should be "234 lines aren't covered by any test". Bonus, this way a change that deletes covered code won't negatively affect the metric.
The article focuses on engineering abilities, but strong engineers excel in areas outside just engineering.
You don’t need to be some prodigy who invents the next great thing, you just need to be the person who can come up with a plan under pressure, know where things need to happen and make sure things can execute.
The strongest engineers that I’ve met, even just on a programming level are fundamentally just better at planning and executing a plan than weaker engineers. They’re not necessarily better skilled at the actual coding aspects.
My theory is that devs like writing these articles because it implicitly means they're toward the better end of whatever made-up spectrum they're pushing. After all, why would anyone care for a weak engineer's thoughts on what makes a strong engineer?
I don't think that's fair at all. Every engineer should regularly reflect on where they could improve, and that necessitates understanding that you're not good at all things. A weak engineer sharing those thoughts is just as useful as a strong engineer sharing them.
Many engineers feel their work is not seen. Management rarely looks at their output let alone the code. Seeing a (supposedly) weaker engineer beeing promoted instead will make you think about how to succeed next time.
I get this vibe from HN comments that refer to "juniors". Because it's a frequent occurrence, whether they mean it or not, I think they get a small kick out of placing themselves above others.
I don't entirely agree with the article, but there are some aspects I to agree with, perhaps for different reasons.
In my experience a key differentiator is passion. Folks who are passionate about a subject will typically explore it more, and thus have a wider array of experiences and tools to draw on. This makes them able to solve problems others cannot.
It's not so much that the others couldn't ever do it, but they might simply not know enough to ask the right questions to get started or similar.
It's not a 1:1 correspondence, but it is in my view a strong signal.
That said, there are many different aspects to being a good engineer, and most are stronger in some and weaker in others. A good team has a good mix.
Folks who are passionate about a subject will typically explore it more...
The problem with this idea is that in most orgs 'passion' equates to putting in more hours, taking problems home, etc. That implicitly biases the org against people with children, people with caring duties, people with other hobbies, and people who might be incredible engineers but who are just there for the job. That bias makes the company weaker.
I don't think the existence of bad company politics refutes the idea that passion might be a differentiating attribute among all of these groups of employees.
A dev can be passionate 20h/week and solve cursed bugs and architecture issues while another only ever does straightforward tickets 40h/week (and both can be more or less adequate, depending on the situation).
I do think it is rather passion as opposed to say, experience, seeing how some devs are drawn to the occasional tricky task early on.
Of course this "passion" could be many things. Curiosity, a higher than average frustration tolerance, an appreciation of "virtual" successes, a desire to prove oneself on an intellectual level (perhaps even in a compensative way), having the chutzpah to set own priorities on the way forward, ...
> The problem with this idea is that in most orgs 'passion' equates to putting in more hours
I meant passion in a more absolute sense, not just working more hours but being curious to explore and wanting to learn more about the field, in the "basic research" kind of sense.
While certainly there's overlap between passion and spending extra hours in the field, for example learning about other programming languages at home as a personal project in our case, it doesn't have to be in my experience.
Though in that case it likely would require the org realizing they benefit from and want to retain such passionate individuals.
"Passion" is an overused term, but it's absolutely clear that developers who love what they do are nearly an order of magnitude better than those who are punching the clock.
In a very specific sense, I tend to perform reverse-age-discrimination, because a developer who was PEEKing and POKEing segmented address space with BASIC in 1984 as a kid is always going to be preferable to an aimless Zoomer who was "inspired" by Justin Timberlake saying "A million isn't cool anymore, you know what is cool? A Billion." in The Social Network.
Until now I believed him when he told me he was a strong engineer working at Google, and eats at the Google cafeteria ... He's just too proud. I will make sure to leave some milk out every night from now on.
You can say you can play chess because you know the rules and how the pieces move - weak engineers most likely know how to program, they know the syntax and general idea how it works.
Then you can have regular players who can play the game and know openings etc. So they will plough through someone who just knows the rules.
Then there are grand masters who are playing on level where regular players are not even close even if they play a lot.
Important part of this analogy is that in chess it is so clear cut - but for eng roles it is of course fuzzy.
But it is easy for anyone to try to play against different levels of chess players to understand what is the difference. You can set computer program to emulate players or hit any online chess platform.
"...There are fencers that seriously train that can barely score a point on me. I can barely score against the top guy in Australia. That guy can barely score against someone trying to make the Olympics, and that guy can probably barely score against the guy that actually won the whole thing."
Weird how hostile a lot of the comments are at the time of writing. It's almost like they are people who are strong at coding but not good at planning and can't progress, or they are are stronger than they think they are.
If you've actually read the whole article you'd realize that it's not an elitist take on what a strong engineer is. The opinions are quite reasonable and if you ask anyone you genuinely respect as good engineers you'll probably get similar opinions about strong, regular, and weak engineers.
From my experience, the more problematic ones are the weak _senior_ engineers and the tactics described in the article only scratch the surface of the kind of the tactics they use to keep that senior title and looking good in the eyes of clueless management. If your company is _keeping_ one of those as a mangers, you have basically screwed up the entire subtree from that node.
It's a pretty good article. My only criticism is that the author is too kind and too generous to the weak senior engineers.
I disagree. The author calls some engineers zeros and i have never actually met a zero engineers, but i sure have seen egalitarean price treat people like that and subsequently get no output. That's a failure of the author/engineers leader, not an IC.
I'm going to go against the grain on this one but I think it's a good article. I think it should have focused more on the positive sides and the advice and less on the blame game, or even explaining how "weak" engineers survive in organisations. Having spent a couple of decades in the SWE industry, a couple of years in management, I've worked with quite a lot of "weak" senior engineers. In Denmark it's common to take some university level MBA courses as you transition into management and I did that, and it's been helpful as I went back to being an engineer. When I work with a "weak" engineer I let them know they can ask for advice on management if they want to in the most non-intrusive way possible. Some of them do, others don't and I never push it.
What I really like about this article is that it outlines some really good advice. I think the "asshole" part should've been emphasized more. To me you cannot be a "strong" engineer if you're an asshole. Not only will people not want to work with you, but you're extremely likely to lower team morale and create an unproductive work environment. This is where anyone goes from being a "torch bearer" to being "just an employee", and while just doing what you're paid to do is fine in my book, it's when people thrive they have the most fun at work. Another part I think this article could've highlighted more is how you can help juniors find their way into "seniority" by giving them good advice. I don't think you should in anyway undermine a "weak" senior engineer when you do this, but I do think you should nudge people in the right direction. I think you should do this under any circumstance though. You can also be assertive with your "weak" engineer and tell them to not exploit juniors in a nice way. I hate saying "journey" but part of what you should learn as you grow into your career is that it, is, just work. This piece of advice is excellent, since it'll give you a more nuanced view on workplace cutlture and politics. Unproductive people are not your problem, let them be unproductive and let the company handle deal with it. You can be friends with them as the article outlines, but you shouldn't carry them beyond what is reasonable.
What I think the article does wrong is that people transition between these roles more than it outlines. You can be a "strong" engineer in some periods of your life and a "weak" engineer in others. I think it's also important to recognize this in your coworkers. Why are they being unproductive? Is it because their baby has kept them awake for a month straight? Is it because they have been given too much responsibility by the business? Is it because they've been put in the wrong role? There can be a lot of reasons, and I think the most "classic" one is when people don't know how to transition from engineering and into management, or when the business demands that they do 100% of their old job while also managing a team.
I went back to engineering because it turned out I was neurodiverse, and this stressed me out when I had to manage people. One of the sobering lessons I took with me, however, is how replacable we all are. It's always just a question of cost. Similarily when you're hiring for a position, you can basically pick the top 10 candidates and throw a dart arrow at them and be fine. You obviously shouldn't do this, but it's quite a different perspective than what I had from being hired where I figured it was all about being "the best".
This is an article about nothing. It states that great employees deliver great results, average employees deliver average results and bad employees deliver bad results. What a waste of time.
The article posits that bad employees don’t just deliver bad results, but rather no results at all other than the ones gifted to them by good engineers who should probably be spending their time doing something other than keeping dead weight afloat. It’s a different perspective on what to look out for in a bad hire and the penalties of such a mistake.
Maybe you’ve been lucky enough to not experience that in your career.
Strong engineers can execute code in their mind without needing a debugger.
I'm not a strong engineer, my friend is. We're not talking a few lines of code here. We're talking about going through a few hundred lines of code and not making a single mistake.
96 comments
[ 2.7 ms ] story [ 159 ms ] threadTesting strong engineers to destruction in a lab should only be carried out by competent materials scientists.
I think this comment does that. In article weak engineers are ones who cannot deliver anything.
That apart, I think there's something to the "stronger in a group" principle.
Weak engineers sap energy from other people making excuses and hunting down people who can do work for them - that is the definition from the article.
You end up with thousands of lines of insecure, buggy code that will most likely be scrapped.
The cheapest way to build things is a small team of strong engineers in my experience
And likewise, I have seen technically weak engineers who are capable of getting along with others deliver great output with high business value.
Imho, the fact the author calls some engineers "0's" is the type of egalitarian douchenozzelry that I have seen bring entire teams to a halt, and why I think the author comes off as a blow hard. If you think any person is a zero, the more likely truth is you don't know how to properly asses a person's skills and put them to use where they fit - and that's an eng leadership failure, not an ic failure.
Yea an intelligent, motivated and capable individual has more significant output than someone who isn’t - and?
I don’t get what the point of this article is tbh… this is the same in every other field of human endeavour
- Some people are at this ALL day, that’s why they are good and getting better.
- Some people take DRUGS to do this all day.
- Do not doubt the sheer hours it takes to get good.
- Some engineers get worse because they practice the wrong things (whatever it is, could be a bad coding practice, it could be bike shedding, etc)
- Practice is a vector, it has magnitude and direction. Stop marveling at the final product of practice and marvel at practice itself. It’s powerful in either direction, it can lift you or keep you stuck in a Sisyphean loop.
Practice just means you'll get better at doing what you're doing. If what you're doing is wrong or lame then you'll just use even fewer brain cycles to do the wrong thing.
Improvement only comes when someone specifically seeks out to change the way they're doing things.
If they don’t sacrifice their life for their job they get deported after all.
It is funny that this article is what we ended up from that beginning tho.
Link?
https://xcancel.com/VivekGRamaswamy/status/18723121399452345...
Basically "groypers" and literal neo-nazis are whining about Indians on X. Instead of ignoring them people like Elon Musk and Vivek are going full-defensive mode about the current dysfunctional H1B visa system.
Honestly it seems like the American Right have convinced themselves that Xitter is now real life and that they have to engage even the most stupid neo-nazi trolls.
You know them?
So what about the -10x engineers? One trick that gets what the article calls 'weak' engineers to senior is procrastinating solving the business problems (they are weak engineers ergo they _can't_ solve the business's problems) and focusing instead on the toil of process, which they tend to inflate and extend. And this checks the boxes that managers are using to evaluate engineers and promote them.
I've seen weak senior engineers completely tank whole dev orgs by overarchitecting the CI and adding gazillions of brittle tests and completely taking away any chance of the strong engineers ever getting solutions to the business's problems into production!
Wow I thought I was the only one who saw such a thing. Glad I'm not alone
I don’t know what to say about this. I remember this one dev who was super obsessed about code coverage (like, the actual coverage number - this detail is important). I don’t think this person even gave a shit about the tests, it just has to tick off that 90%+ test coverage metric which he was obsessed with, and the code needed to look exhaustive. I know this because that’s what his tests were exactly like.
The tests were like the lamest tests ever, but they appeared comprehensive and exhaustive. It never really added much to the app, and it was just insane busy work.
How do you tell a business this an absolute waste of money? You can’t because culturally code coverage is good.
So I don’t even know who to blame here. This kind of shit happens constantly because we built some kinda tech culture that incentivizes it. We as an industry seem to have a really hard to time telling a 20 something (who may or may not be jacked up on stimulants) to settle the fuck down.
How do you tell many many many developers that the reason they shouldn’t focus on certain things is because it’s a waste of money?
This not a topic that comes up a lot because most developers are divorced from the bottom line.
Anyway, this topic can head off in all kinds of directions.
The same program can be represented in many different ways. And code is data.
We can take the program and compile it to a byte code. We then represent the byte code as an array of bytes which is bundled with the virtual machine to make the working program.
The byte code uses every instruction of the virtual machine. And so, wee, we have 100% code coverage.
Of course not 100% of the byte code array is executed by the VM, but pay no attention to that. Code coverage is about code, not data!
The only coverage that matters is the coverage of the state space: hitting all the cases that can occur. There isn't a nice one-to-one correspondence between control flow paths and cases. A routine which adds to unsigned 16-bit integers has 65536 x 65536 cases, but nowhere near that many paths through its control graph.
Oh, you are lucky. Where I work that's the person who defines how to test and which tools to use. Look at the code, create tests to paint everything green. Whether the code actually works does not matter. I don't think these tests have ever caught any kind of bug. That isn't even their purpose.
> So I don’t even know who to blame here.
Money. If tests can be written without understanding what the code is supposed to do, they can be written by people who do not understand. Which appears to be the cheapest way to get passing tests. Not to find any bugs, but that's not what the process requires.
Theoretically yes, but practically not as much as it should be, because we've chosen a bad way to represent the metric. It should be an absolute number and flipped - we don't care about the covered lines, we care about the uncovered lines. Like instead of "90% of the code is covered by tests" it should be "234 lines aren't covered by any test". Bonus, this way a change that deletes covered code won't negatively affect the metric.
You don’t need to be some prodigy who invents the next great thing, you just need to be the person who can come up with a plan under pressure, know where things need to happen and make sure things can execute.
The strongest engineers that I’ve met, even just on a programming level are fundamentally just better at planning and executing a plan than weaker engineers. They’re not necessarily better skilled at the actual coding aspects.
I wasn’t planning enough, and it cost a lot. I can highly recommend it.
Or compensate.
I don’t ever expect that my ability to get sidetracked will go away. But I have a system.
And I don’t think I’ll ever get thrilled about algorithms induction proofs. So I just solve other problems.
it is fair and you didn't read the article ;)
(b/c: the author isn't offering anything on how to improve. quite the opposite. it sounds like s/he thinks if you're weak you'll stay weak.)
In my experience a key differentiator is passion. Folks who are passionate about a subject will typically explore it more, and thus have a wider array of experiences and tools to draw on. This makes them able to solve problems others cannot.
It's not so much that the others couldn't ever do it, but they might simply not know enough to ask the right questions to get started or similar.
It's not a 1:1 correspondence, but it is in my view a strong signal.
That said, there are many different aspects to being a good engineer, and most are stronger in some and weaker in others. A good team has a good mix.
The problem with this idea is that in most orgs 'passion' equates to putting in more hours, taking problems home, etc. That implicitly biases the org against people with children, people with caring duties, people with other hobbies, and people who might be incredible engineers but who are just there for the job. That bias makes the company weaker.
A dev can be passionate 20h/week and solve cursed bugs and architecture issues while another only ever does straightforward tickets 40h/week (and both can be more or less adequate, depending on the situation).
I do think it is rather passion as opposed to say, experience, seeing how some devs are drawn to the occasional tricky task early on.
Of course this "passion" could be many things. Curiosity, a higher than average frustration tolerance, an appreciation of "virtual" successes, a desire to prove oneself on an intellectual level (perhaps even in a compensative way), having the chutzpah to set own priorities on the way forward, ...
I meant passion in a more absolute sense, not just working more hours but being curious to explore and wanting to learn more about the field, in the "basic research" kind of sense.
While certainly there's overlap between passion and spending extra hours in the field, for example learning about other programming languages at home as a personal project in our case, it doesn't have to be in my experience.
Though in that case it likely would require the org realizing they benefit from and want to retain such passionate individuals.
-Kevin Kelly
In a very specific sense, I tend to perform reverse-age-discrimination, because a developer who was PEEKing and POKEing segmented address space with BASIC in 1984 as a kid is always going to be preferable to an aimless Zoomer who was "inspired" by Justin Timberlake saying "A million isn't cool anymore, you know what is cool? A Billion." in The Social Network.
Nothing makes the stupid angrier than someone explaining stupidity.
"Ooooohhh!" --Yosemite Sam
You can say you can play chess because you know the rules and how the pieces move - weak engineers most likely know how to program, they know the syntax and general idea how it works.
Then you can have regular players who can play the game and know openings etc. So they will plough through someone who just knows the rules.
Then there are grand masters who are playing on level where regular players are not even close even if they play a lot.
Important part of this analogy is that in chess it is so clear cut - but for eng roles it is of course fuzzy.
But it is easy for anyone to try to play against different levels of chess players to understand what is the difference. You can set computer program to emulate players or hit any online chess platform.
https://ludic.mataroa.blog/blog/you-must-read-at-least-one-b...
"...There are fencers that seriously train that can barely score a point on me. I can barely score against the top guy in Australia. That guy can barely score against someone trying to make the Olympics, and that guy can probably barely score against the guy that actually won the whole thing."
If you've actually read the whole article you'd realize that it's not an elitist take on what a strong engineer is. The opinions are quite reasonable and if you ask anyone you genuinely respect as good engineers you'll probably get similar opinions about strong, regular, and weak engineers.
From my experience, the more problematic ones are the weak _senior_ engineers and the tactics described in the article only scratch the surface of the kind of the tactics they use to keep that senior title and looking good in the eyes of clueless management. If your company is _keeping_ one of those as a mangers, you have basically screwed up the entire subtree from that node.
It's a pretty good article. My only criticism is that the author is too kind and too generous to the weak senior engineers.
Absolutely. There is 0 need to act as if there was a personal tragedy. This is bad advice.
What I really like about this article is that it outlines some really good advice. I think the "asshole" part should've been emphasized more. To me you cannot be a "strong" engineer if you're an asshole. Not only will people not want to work with you, but you're extremely likely to lower team morale and create an unproductive work environment. This is where anyone goes from being a "torch bearer" to being "just an employee", and while just doing what you're paid to do is fine in my book, it's when people thrive they have the most fun at work. Another part I think this article could've highlighted more is how you can help juniors find their way into "seniority" by giving them good advice. I don't think you should in anyway undermine a "weak" senior engineer when you do this, but I do think you should nudge people in the right direction. I think you should do this under any circumstance though. You can also be assertive with your "weak" engineer and tell them to not exploit juniors in a nice way. I hate saying "journey" but part of what you should learn as you grow into your career is that it, is, just work. This piece of advice is excellent, since it'll give you a more nuanced view on workplace cutlture and politics. Unproductive people are not your problem, let them be unproductive and let the company handle deal with it. You can be friends with them as the article outlines, but you shouldn't carry them beyond what is reasonable.
What I think the article does wrong is that people transition between these roles more than it outlines. You can be a "strong" engineer in some periods of your life and a "weak" engineer in others. I think it's also important to recognize this in your coworkers. Why are they being unproductive? Is it because their baby has kept them awake for a month straight? Is it because they have been given too much responsibility by the business? Is it because they've been put in the wrong role? There can be a lot of reasons, and I think the most "classic" one is when people don't know how to transition from engineering and into management, or when the business demands that they do 100% of their old job while also managing a team.
I went back to engineering because it turned out I was neurodiverse, and this stressed me out when I had to manage people. One of the sobering lessons I took with me, however, is how replacable we all are. It's always just a question of cost. Similarily when you're hiring for a position, you can basically pick the top 10 candidates and throw a dart arrow at them and be fine. You obviously shouldn't do this, but it's quite a different perspective than what I had from being hired where I figured it was all about being "the best".
Maybe you’ve been lucky enough to not experience that in your career.
Only strong engineers can do things that have never actually been done.
Conclusion, there are no strong engineers
I hope you enjoyed my fake AI logic
I'm not a strong engineer, my friend is. We're not talking a few lines of code here. We're talking about going through a few hundred lines of code and not making a single mistake.