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 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.

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.

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.

> 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.

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.

> 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.

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".

> 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.

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!

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.

> 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.

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.

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.

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

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.

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".

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.

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.

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.

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

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.

"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

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'm all for it, if they are paid 10x that is.

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.

I think my cat is a weak Engineer!

“Strong” engineers don’t refer to others as “weak”.

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.

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.

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.

Lift heavier weights

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.

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.

[dead]

[flagged]

[flagged]

[flagged]