Today people are blowing up on Twitter about whether the USA should be importing top talent from other countries, and whether that means American engineering talent at home is weak. Last month, people blew a study which is said to show that ~9.5% of software engineers are effectively unemployed, and effectively defrauding the company. And for the last ten years, people have been talking and writing about the fable of the “10x engineer”.
What does it really mean to be a strong software engineer?
Strong engineers
In my experience, the true measure of talent is not speed or volume of output, but the ability to perform tasks that other engineers cannot. In other words, strong engineers can do things that weaker engineers can’t, even in all the time in the world. So, the strongest engineers are stronger than people think they are: not 10x as strong as the median engineer, or even 100x, but infinity-x in some problems. The weakest engineers are weaker than people think they are: not 0.1x, but 0x. They cannot perform almost any tasks that a large software organization needs to perform.
For example, there is a difficult division between engineers who can deliver complex projects and incompetent engineers. It’s not like weaker engineers do it any slower – they just can’t of all. Either a nearby powerful ghost engineer leads the project or the project fails. Some more examples of capabilities like this:
- Resolve very difficult bugs (eg race conditions in multiple services)
- Deliver meaningful improvements to the most thorny parts of legacy codebases
- Successfully make changes that require a major re-architecture
For the top end of the strongest engineers, the capabilities become things like “improving SOTA for large language models” and “making self-driving cars work”.
Not every strong engineer can do all these tasks. Someone may be good at solving difficult bugs but not able to ship projects, or good at legacy codebases but not able to move fast. However, if a person is good at one of these things, they are likely to be good at most of the others. I don’t really know why: maybe it’s raw intelligence, or being good at something helps you learn from others, or that these capabilities are more similar than they seem, or that these kinds of engineers are working hard on everything. But in my experience it is true.
I want to be clear that while being able to do an individual task is pretty black-and-white, the strong/regular/weak categories exist on a spectrum. It’s possible to have a “regular engineer” who may be good at fixing difficult bugs, or a “weak engineer” who is really good at maintaining their dev environment. You may be on the fuzzy border between the two categories.
Regular engineers
Under strong engineers, you have regular engineers who make up the majority of most companies. Here are some examples of the capabilities you can expect these engineers to have:
- Fix 95% of bugs (eg normal, non-cursed bugs)
- Get and deliver most tickets in JIRA
- Removing themselves from dev env issues is common at the time
A long-time colleague once referred to this type of engineer as a “plodder”: they’re not particularly fast, but they’ll keep making progress on a normally difficult engineering task. I think now “plodder” is an unnecessary pejorative name for it, because the more experience I get the more I love these guys. they HELP. they do the work. They’re not just burning with ambition to succeed in the next promo cycle, or to blow away their peers with impressive output. Maybe they have other things going on in their lives!
I have little to say about this group, except to warn against confusing it with the last group: weak engineers.
Weak engineers
Another category is really weak engineers. These people have little or no capabilities at all. In other extremes, the baseline difficulty of a normal-to-easy software task is beyond what they are comfortable with. I think some of these people are overworked or fraudulent in some way, but I think it’s mostly a lack of ability. I want to make it clear that I am not exaggerating here: weak engineers cannot complete almost any engineering task. I work in teams that don’t have anything, but if you’re in the industry enough you’ll run into them.
Ironically, while people like this exist at almost all levels of seniority, you are more likely to encounter weak engineers in senior roles. I think this is probably due to two reasons. First, the bar for hiring juniors is clearly based on capability, so it’s harder to cross. In interviews, older people may talk about the work they are involved in, which is difficult to distinguish from the work they have done. DOING. Second, a weak junior is usually given more opportunities to learn, because it is socially acceptable for them to not know things. A frail old man must hide his lack of knowledge and learn in secret, which is more difficult.
I don’t have much to say about the weak juniors. You have to help them, teach them challenging problems, and see if they can improve and learn. The frail elders, however, are more interesting.
How can weak senior engineers survive?
How can weak engineers survive at senior+ level? They have many one-way pairings. When you pair up with these engineers, it’s a bad experience, because you have to do all the work, whether it’s driving or navigating. Usually the pairing is careful – they quietly contact another engineer on the DMs team for help with every task they have. Sometimes there is an unlucky victim who uses their time like this: for example, an effective junior in the team who is happy to help and is not experienced enough to know more. More experienced weak engineers will round-robin their matchmaking across the team, so each individual member may need to chip in every week or so. Only when everyone compares notes will it be clear that the weak engineer matches 100% of their tasks.
Weak engineers are often surprisingly active in work-related discussions. This is because they have a lot of time – unless they find someone to “match”, they don’t really work. It is also an effective defense mechanism. If there are questions about their individual output, they can gesture to their public communications as evidence that they are raising the team instead of grinding out concrete work. One way to tell a weak engineer in a discussion thread about some problem is to see who brings up specific facts about how the system currently works, and who does of general recommendations applicable to any system. If their messages were all public tweets, they probably didn’t add much value.
Some tips for working with vulnerable senior engineers
The first and most important thing is to remember that it’s just work. Someone being bad at their job doesn’t make them a bad person. Don’t be fooled! People can be weak through laziness and lack of talent, but also for all kinds of personal reasons that are none of your business. Act with the generosity you hope you’ll receive if you’ve suffered some personal tragedy that means you can’t focus on work. Even the lack of talent can be specific to the context: for example, they may be an embedded system that tries in different fields and does not have much success, or an employee of a large company that struggles to adapt to the norms of the startup .
However, you must protect your time. Don’t quietly give up hours of your workday to help them stay afloat. One tactic is avoid time-asymmetrical helping. Don’t do work for them that takes more time than they need to ask about it. For example, if you are asked “hey, I have an issue, how do you approach it”, don’t take the time to work on the actual solution and give it to them. Fire a easiness answer that directs them to the next immediate step (eg “oh yes, it looks like a billing code thing, you should see how service X handles it”). This means they can’t spend minutes of their day tying up your hours.
Relatedly, you should try to protect the time of junior members of your team. Don’t let the weak seniors take advantage of them who ask them to solve their problems and then frame them to the management while they help the juniors to level up. The best way to do that is to (professionally) make sure your manager is aware of the situation. It can be a very difficult process to manage people in some companies (and there may be things you don’t know about), so don’t expect this person to get fired/pipped/told to shape up. But you still have a responsibility to make sure your manager knows.
CONCLUSION
Engineering talent is not excessive speed or output, it is the ability to perform tasks that other engineers cannot. That’s why the weakest engineers produce less, and why tech CEOs worry about hiring the strongest engineers.
Most engineers can perform a wide range of normal work tasks, but some can perform very difficult ones and others can barely perform. Perhaps you should try to expand the set of tasks that you are comfortable doing. If you are working with a weak engineer, be nice but protect your time.
2024-12-27 07:16:00
