I think 10x engineers do not actually exist, but maybe 0.1x engineers do, and when a 1x engineer is in such an environment they may seem like 10x by comparison.
I think both 0.1x engineers and 10x engineers exist.
0.1x engineer: one of my friends works at a certain government contractor. One of her coworkers had difficulty understanding short circuiting in evaluating boolean statements, everything he writes she needs to fix, he thinks XML is a programming language, and it's just a huge mess amongst a huge list of other complaints.
10x engineer: Actually, he's still in undergrad. I was his TA for a VR class and he made a pretty great clone of Beat Saber before it was released just from watching the trailer, and in under a week. He's never heard of Leetcode, yet is absolutely comfortable with interview questions (well, I decided he didn't need practice after asking a few questions...). He's had an internship at a FAANG and finished his project early and got bored. I introduced him to a few of my other friends in the industry and they are intimidated by him too. He's this rare combination where he has the theoretical knowledge of CS, but also excels at actual engineering work.
Both 0.1x engineers and 10x engineers just feel like they re on a "different level". I don't know how else to describe it .
As for whether or not looking for 10x engineers is practical, I don't think it is.
1) It took me way too long to confirm that feeling (i.e. I imagine interview questions alone aren't enough; you have to see the engineer working).
2) I imagine most companies don't even need a 10x engineer to build the product they need.
3) They're too rare. How do I know? Because (a) none of my friends have felt that before meeting him and (b)the whole industry is still debating on whether 10x engineers exist.
> 2) I imagine most companies don't even need a 10x engineer to build the product they need.
So true. 99% of businesses are CRUD and "complex-because-of-humans" business logic very rarely needs someone like Michael Abrash as a chief scientist to get the job done.
There are different ways of making teams more productive than doing just technical work.
For my own anecdote, I often can fix a lot of bugs/feature requests that come by in < 10 minutes, and often will. As soon as it is revealed that another dev will start contributing who has no prior experience, I stop most of that work and let that person take on some of those tasks & do the leftover ones. Mentorship/growing developer capabilities expands capabilities long term, even if the dev ends up moving to another project.
I also spend the most time in meetings of any IC on my team - reducing how many ICs are in meetings frees up their time to learn and grow.
I often float ideas to people for approaches to problems and designing apps/systems/features - I’ll also let others do the same. However, I also often take a light touch and leave ultimate decision making to others so they can gain that experience even if I disagree. Letting others take ownership improves the team’s capabilities.
There are many ways to expand productivity of those around you that even those who aren’t as technically gifted can do. Leadership is a very underrated part of being an engineer IMO. I do all these things as a mid-level engineer in title, but gained massive respect from management & senior ICs where they come to me for advice/ideas. I don’t fall into the trap of jealousy that others are getting credit/hampering my ability to get promoted because my work speaks for itself & I celebrate when others do well - I have no reason to feel insecure, and so help unlock my team’s productivity by removing that ego in my actions.
It takes a very healthy work environment (and attentive management) for this kind of work to be noticed and rewarded. Unfortunately it's not often the case.
I have tried to take this approach many times and a lot of companies/managers absolutely do not value it.
Broadly speaking, it only works if management is really involved in the day-to-day (more like hour to hour, really) process of what you're doing. Then it is easy for them to see that you are lifting up those around you and elevating the team as a whole. Without this involvement, a "mentor" and "leader" winds up looking simply like "a guy who doesn't ship enough" to management.
At my last job, management was very... absentee. There was a shortage of management and this was a bottleneck. They relied on metrics too heavily (stories shipped, etc) and didn't understand the actual processes... who was mentoring and elevating others, and who was "highly productive" but was also leaving an absolute trail of technical debt in their wake.
It's a shame when management fails at understanding this aspect of the game because I feel like it's one of the simplest ones to understand.
Appeasing clients? Balancing profit/loss? Juggling fire-fighting and feature-shipping? Recruiting? Hiring?
Hard, hard, hard, hard, hard.
Listening to your developers, who generally just want to be productive and generally know more than anybody else about how they can be productive? (If not, why did you hire them, if they don't know how best to do their jobs?) Understanding that technical debt exists and exerts a massive drain on future productivity?
I feel like those are the easy parts of the job.
Of course, the onus is on developers to communicate these things well. Otherwise we can't blame management for not understanding them. But I have never seen process break down because developers weren't talking. It always seems to fail because management isn't listening.
