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.
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.
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.
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.
> 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.
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.
Readit News
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.)
Deleted Comment
Deleted Comment
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.
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.
-Kevin Kelly
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.
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.
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.
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.
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.
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.