What can strong engineers do that weak engineers can't?(seangoedecke.com)
seangoedecke.com
What can strong engineers do that weak engineers can't?
https://www.seangoedecke.com/weak-engineers/
96 comments
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 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.
[deleted]
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.
> where they could improve
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.
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.
> I don't think that's fair at all. Every engineer should regularly reflect on where they could improve,
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.)
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.)
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.
[deleted]
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.
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.
"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.
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.
Enthusiasm is worth 10 IQ points
-Kevin Kelly
-Kevin Kelly
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.
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, ...
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.
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.
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.
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.
Someone recommended the book “how big things get done” here some time ago and it’s improved my approach to almost every new project since I read it.
I wasn’t planning enough, and it cost a lot. I can highly recommend it.
I wasn’t planning enough, and it cost a lot. I can highly recommend it.
I recommend that book and also "Coders At Work". I got gud after reading those two books.
Maybe it says more about the places I worked in than my preferences, but IME the software issues rarely require superhuman engineering ability.
Rather, the excellent SEs have taken moderately complex problems and solved them very well. Maybe not super fast, but the solution worked first time, worked under the anticipated load, was very debuggable, easy to extend and futureproof. Where the spec was ambiguous, wise decisions were taken. Or more generally, what you get back is better than what you asked for.
The converse is clear. You get something, maybe quickly, maybe not. But it takes weeks and months of snagging, doesn't quite do what is required, and at the first sight of adding some basic features, it turns out to be impossible.
Rather, the excellent SEs have taken moderately complex problems and solved them very well. Maybe not super fast, but the solution worked first time, worked under the anticipated load, was very debuggable, easy to extend and futureproof. Where the spec was ambiguous, wise decisions were taken. Or more generally, what you get back is better than what you asked for.
The converse is clear. You get something, maybe quickly, maybe not. But it takes weeks and months of snagging, doesn't quite do what is required, and at the first sight of adding some basic features, it turns out to be impossible.
How are you calibrating your perception of complexity of engineering tasks?
This post mentions for example complex bugs across many services. Other similar posts write about scaling to millions and billions of users, designing novel algorithms... My point is, great engineers often do fairly mundane things, just very, very well.
> In my experience, the real measure of talent is not the speed or volume of output, but the capability to do tasks that other engineers can’t.
This is a great point. People hear "10x" and assume it's a multiplier for the raw output. But it's really a multiplier for the impact of the work. No one can type or think 10x faster than the average - but their ideas can be 10x better.
A strong engineer and a weak engineer may produce the same amount of code in the same time, but the strong engineer's code solves more complex problems more robustly, resulting in more value per line of code. In a sense, strong engineers are defined by what they don't do - they don't waste their time on low-impact work.
This is a great point. People hear "10x" and assume it's a multiplier for the raw output. But it's really a multiplier for the impact of the work. No one can type or think 10x faster than the average - but their ideas can be 10x better.
A strong engineer and a weak engineer may produce the same amount of code in the same time, but the strong engineer's code solves more complex problems more robustly, resulting in more value per line of code. In a sense, strong engineers are defined by what they don't do - they don't waste their time on low-impact work.
The reason an article like this are so irritating is because it has such a narrow view of peoples capabilities and diminishes folks that dont fit in a narrow spectrum.
I worked at a company that took 3 years to migrate a few services across k8s clusters, a task that would normally take me just 3 months. They he-hawed because I hadn't learned to write go though, so they thought I was the retard somehow. No one could run the entire app locally but me, but I don't write Java.
The moral is, different engineers have different strengths, and if your running around thinking people are zero's - the problem is likely with leadership, and not the IC. In this case, the author seems like a week, inexperienced leader, not a great engineer.
I worked at a company that took 3 years to migrate a few services across k8s clusters, a task that would normally take me just 3 months. They he-hawed because I hadn't learned to write go though, so they thought I was the retard somehow. No one could run the entire app locally but me, but I don't write Java.
The moral is, different engineers have different strengths, and if your running around thinking people are zero's - the problem is likely with leadership, and not the IC. In this case, the author seems like a week, inexperienced leader, not a great engineer.
> Weak engineers are often surprisingly active in work-related discussions.
Hits the nail on the head. I don't think it's an engineers fault though.
If the company culture rewards buzzwords over code and endless meetings over real progress this kind of behavior becomes inevitable. When shipping features takes a back seat to writing "thought leadership" blog posts or chasing pointless metrics, people adapt to survive in that environment.
It's not about bad engineers, it's about a system that incentivizes all the wrong things.
Hits the nail on the head. I don't think it's an engineers fault though.
If the company culture rewards buzzwords over code and endless meetings over real progress this kind of behavior becomes inevitable. When shipping features takes a back seat to writing "thought leadership" blog posts or chasing pointless metrics, people adapt to survive in that environment.
It's not about bad engineers, it's about a system that incentivizes all the wrong things.
Thank you for an interesting categorization and highlighting dynamics between the categories.
Reading the article, I get the sense that being more specific in communication is a sign of better performance capability, whereas generalized communication hints at the opposite.
> "One way to tell a weak engineer in a discussion thread about some problem is to see who is bringing in specific facts about how the system currently works, and who is making purely general recommendations that could apply to any system."
This observation of specific versus general communication seems to surface also when being asked a question. If the question is specific, it hints at competence and effort.
> "One tactic is to avoid time-asymmetrical helping. Don’t do work for them that takes much more time than it took them to ask about it."
The general question offloads, to the one being asked, the work of getting down to concrete details. A specific question on the other hand relies on the questioner having done the cognitive work of comprehension before asking.
A general question deserves a counter question that encourages the questioner to become more specific. In a real world environment, I can imagine—just as the article also points out—there being many factors like stress etc, influencing the communication.
Reading the article, I get the sense that being more specific in communication is a sign of better performance capability, whereas generalized communication hints at the opposite.
> "One way to tell a weak engineer in a discussion thread about some problem is to see who is bringing in specific facts about how the system currently works, and who is making purely general recommendations that could apply to any system."
This observation of specific versus general communication seems to surface also when being asked a question. If the question is specific, it hints at competence and effort.
> "One tactic is to avoid time-asymmetrical helping. Don’t do work for them that takes much more time than it took them to ask about it."
The general question offloads, to the one being asked, the work of getting down to concrete details. A specific question on the other hand relies on the questioner having done the cognitive work of comprehension before asking.
A general question deserves a counter question that encourages the questioner to become more specific. In a real world environment, I can imagine—just as the article also points out—there being many factors like stress etc, influencing the communication.
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!
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
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.
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.
> [...] 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.
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.
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.
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.
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.
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.
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.
> A long-ago colleague once referred to this type of engineer as a “plodder”: they aren’t particularly fast, but they’ll make steady progress on a normal-difficulty engineering task. I now think “plodder” is an unnecessarily pejorative name for this, because the more experience I get the more I love these colleagues. They help. They do the work. They’re just not burning with ambition to excel at the next promo cycle, or to blow their peers away with really impressive output. Probably they have other things going on in their lives!
I'd like to propose "tortoise", as in the fable "the tortoise and the hare" - not fast, but very reliable and will finish normal tasks. So then a hare would talk/present themselves well but doesn't get much done (the post's weak seniors?). These also combine nicely with that acronym that recently got popular, GOAT (greatest-of-all-time) - the best who do the unexpected, like walk on walls.
I'd like to propose "tortoise", as in the fable "the tortoise and the hare" - not fast, but very reliable and will finish normal tasks. So then a hare would talk/present themselves well but doesn't get much done (the post's weak seniors?). These also combine nicely with that acronym that recently got popular, GOAT (greatest-of-all-time) - the best who do the unexpected, like walk on walls.
One way I think of it is chess analogy.
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.
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.
Ludicity wrote about exactly this a little while back:
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."
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."
> In my experience, the real measure of talent is not the speed or volume of output, but the capability to do tasks that other engineers can’t.
Unfortunately many tech companies have become so bureaucratic that a strong engineer is the person who can excel in the most important meetings. They are either in meetings or on the way to a meeting. Over the years, they gain institutional knowledge at the cost of losing engineering know-how, to the point that they can't even draw good enough boxes. Case in point, just see how many super senior engineers who "specialize" in search and NLP couldn't even articulate a simple RAG pipeline.
Unfortunately many tech companies have become so bureaucratic that a strong engineer is the person who can excel in the most important meetings. They are either in meetings or on the way to a meeting. Over the years, they gain institutional knowledge at the cost of losing engineering know-how, to the point that they can't even draw good enough boxes. Case in point, just see how many super senior engineers who "specialize" in search and NLP couldn't even articulate a simple RAG pipeline.
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.
- 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.
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.
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 :-)
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...
The US would have an easier time hiring overseas talent if immigration wasn't a lottery for visas that makes you tied to your employer.
"make self driving cars"
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
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
What makes an engineer strong versus weak?
The skill is so involved in so many ways, it doesn't seem like there's a simple way to adequately assess a developer. It isn't really like a musical instrument where you can immediately tell from listening to them for 10 seconds how experienced they are.
The skill is so involved in so many ways, it doesn't seem like there's a simple way to adequately assess a developer. It isn't really like a musical instrument where you can immediately tell from listening to them for 10 seconds how experienced they are.
What a strange article. In reality it’s about what they don’t do not “can’t” do.
That headline is easy to answer: lift heavier weights, duh
you are giving the text a little too much credit in my opinion.
The immediate answer that came to mind _before_ I read the article, was "keep things simple". A lot of good things emanate from this mentality.
Superlative achievement in anything -- engineering, art, sport, and even living a joyous life -- all require one most important pair of characteristics: humble seeking of excellence via hard graft.
We first need to set high standards for ourselves, and then undertake honest self-reflection to determine if what we have done is good enough. If it fell short, we must admit it and endeavor to learn how to do better. No, we shouldn't beat ourselves up about it, but we should learn how to work harder and work better by paying better attention to our progress. Over time, we have to learn how our standards, themselves, can be improved.
That is the single most important result of the Dunning-Kruger study: the true experts tended to undervalue themselves because their honest humility did not let them rest on their past achievements and kept driving them forward to ever expand their skillsets. The overconfident non-expert group were so complacent that they were fine weaving a tapestry of lies that they were already above average and needed no further work.
We can each choose to believe anything we want, either honestly correct or mistakenly wrong. We each have the choice, and being humble is the best way to find ever better truths and with them, better results.
We first need to set high standards for ourselves, and then undertake honest self-reflection to determine if what we have done is good enough. If it fell short, we must admit it and endeavor to learn how to do better. No, we shouldn't beat ourselves up about it, but we should learn how to work harder and work better by paying better attention to our progress. Over time, we have to learn how our standards, themselves, can be improved.
That is the single most important result of the Dunning-Kruger study: the true experts tended to undervalue themselves because their honest humility did not let them rest on their past achievements and kept driving them forward to ever expand their skillsets. The overconfident non-expert group were so complacent that they were fine weaving a tapestry of lies that they were already above average and needed no further work.
We can each choose to believe anything we want, either honestly correct or mistakenly wrong. We each have the choice, and being humble is the best way to find ever better truths and with them, better results.
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.
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.
> Vivek thing on twitter
Link?
Link?
Here you go:
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.
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.
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'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".
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 generally pretty true in my experience. Strong engineers really are capable of projects that regular engineers would not complete successfully no matter how much time you give them, and there are also parasitic weak engineers who can't really do much at all, but siphon off their coworkers by convincing them to do their work for them.
I generally agree that weak juniors are not a particular menace, and sometimes just need mentorship and can grow into regular engineers (and perhaps even grow into strong engineers, although personally I have to admit I've never seen that happen). But even growing into a regular engineer is great! It's honest work, and helpful. A regular engineer might not be a superstar but they're the backbone of many large tech teams.
But after over a decade in the industry, I actually disagree about the parasitic weak senior engineers. While I think you can sympathize with them in a non-work context — you can generously assume that they may be going through a hard personal time, etc. — you actually shouldn't tolerate parasitic seniors at work. They're toxic to everyone around them: they leech off their peers, and especially leech off of the enthusiastic junior engineers while providing little or zero mentorship value (and by wasting their time and presenting as if they're useful, they effectively prevent the juniors from establishing useful relationships with helpful mentors), while taking credit for themselves, and they often can successfully blend in as regular, or even strong engineers, at least to managers since as the author notes, they have copious free time to participate in politicking. If not called out (discreetly, to your manager!), some of them inevitably continue getting promoted or at the very least continue "leading" projects while taking credit from the people actually doing the leadership work, which hurts morale since the engineers they've been silently leeching off of know they aren't good — but never told anyone that.
A lot of HN understands the message that "work isn't your family" in the sense that you shouldn't feel you owe your employers the loyalty you would give to family members. But it's important to take that lesson to heart about coworkers, too: if you're being taken advantage of, they aren't your family and they aren't your friend: they're just using you. No one will know that's happening if you don't tell anyone about it! Be discreet, be open-minded — sometimes you'll be wrong, sometimes it's a one-off, etc — but don't keep that kind of abuse to yourself out of misplaced loyalty. It hurts you, your peers, and your juniors.
I generally agree that weak juniors are not a particular menace, and sometimes just need mentorship and can grow into regular engineers (and perhaps even grow into strong engineers, although personally I have to admit I've never seen that happen). But even growing into a regular engineer is great! It's honest work, and helpful. A regular engineer might not be a superstar but they're the backbone of many large tech teams.
But after over a decade in the industry, I actually disagree about the parasitic weak senior engineers. While I think you can sympathize with them in a non-work context — you can generously assume that they may be going through a hard personal time, etc. — you actually shouldn't tolerate parasitic seniors at work. They're toxic to everyone around them: they leech off their peers, and especially leech off of the enthusiastic junior engineers while providing little or zero mentorship value (and by wasting their time and presenting as if they're useful, they effectively prevent the juniors from establishing useful relationships with helpful mentors), while taking credit for themselves, and they often can successfully blend in as regular, or even strong engineers, at least to managers since as the author notes, they have copious free time to participate in politicking. If not called out (discreetly, to your manager!), some of them inevitably continue getting promoted or at the very least continue "leading" projects while taking credit from the people actually doing the leadership work, which hurts morale since the engineers they've been silently leeching off of know they aren't good — but never told anyone that.
A lot of HN understands the message that "work isn't your family" in the sense that you shouldn't feel you owe your employers the loyalty you would give to family members. But it's important to take that lesson to heart about coworkers, too: if you're being taken advantage of, they aren't your family and they aren't your friend: they're just using you. No one will know that's happening if you don't tell anyone about it! Be discreet, be open-minded — sometimes you'll be wrong, sometimes it's a one-off, etc — but don't keep that kind of abuse to yourself out of misplaced loyalty. It hurts you, your peers, and your juniors.
strong engineer = good - weak engineer = bad
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
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
They can stroke their ego by writing pages like that.
Read through the text, and honestly, it's not a very strong argument.
I've worked in my career with exceptionally smart people, with average people and even people I considered somewhat dumb. They all had their strong and weak points, different experiences that they brought to the table in discussions, and it would feel very condescending on my part to divide them in "strong" and "weak". There are at most ones I would like to work with again, and ones that I would rather not.
Read through the text, and honestly, it's not a very strong argument.
I've worked in my career with exceptionally smart people, with average people and even people I considered somewhat dumb. They all had their strong and weak points, different experiences that they brought to the table in discussions, and it would feel very condescending on my part to divide them in "strong" and "weak". There are at most ones I would like to work with again, and ones that I would rather not.
[deleted]
This article fails to acknowledge and appreciate progression in skill level over the years. If it were up to its author, one's skill level would never change.
---
I have seen many so-called talented engineers deliver garbage that has to get thrown out in two years.
---
I have seen many so-called talented engineers deliver garbage that has to get thrown out in two years.
I'm all for it, if they are paid 10x that is.
I think my cat is a weak Engineer!
You feed it every day, don't you? ;-)
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.
Well, I guess my message has permeated the commentariat.
Nothing makes the stupid angrier than someone explaining stupidity.
"Ooooohhh!" --Yosemite Sam
Nothing makes the stupid angrier than someone explaining stupidity.
"Ooooohhh!" --Yosemite Sam
“Strong” engineers don’t refer to others as “weak”.
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.
Testing strong engineers to destruction in a lab should only be carried out by competent materials scientists.
Article mentions not to conflate weak engineers with regular.
I think this comment does that. In article weak engineers are ones who cannot deliver anything.
I think this comment does that. In article weak engineers are ones who cannot deliver anything.
I think you just got whooshed.
That apart, I think there's something to the "stronger in a group" principle.
That apart, I think there's something to the "stronger in a group" principle.
0 times X is still 0 - if you get group of weak engineers as per article you still left with 0. - Even as per joke comment.
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.
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.
Ever seen a large team of weak engineers build in the wrong direction?
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
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
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.
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.
[deleted]
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.
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.
>> Act with the generosity that you hope would be extended to you if you endured some personal tragedy that meant you couldn’t focus on work.
Absolutely. There is 0 need to act as if there was a personal tragedy. This is bad advice.
Absolutely. There is 0 need to act as if there was a personal tragedy. This is bad advice.
[deleted]
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.
Lift heavier weights
My engineer can beat up your engineer.
In the past, most engineers where strong, because computers where heavy
[deleted]
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.
Maybe you’ve been lucky enough to not experience that in your career.
[deleted]
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.
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.
[deleted]
[deleted]
xiaodai(1)
shiroiushi(1)
bflesch(1)