That is actually a failure mode - the engineer that tirelessly works towards an impossible goal.
The 10x engineer has the critical heuristics/intuition/skill to avoid dead-ends, and also the engineering taste to concentrate on technically hard but possible tasks and the skills to deliver.
I more often see junior employees give up on tasks they think are impossible that aren't.
That's physically impossible, unless you're performing some assembly line task like creating a frontend prototype from a marvelapp mock (tons of html, css, js).
Can you do creative work for 10 hours in a stretch, every day.
> One afternoon, I was bent over a program listing while Wendl was staring into space, his feet propped up on his desk. Our boss came in and asked, “Wendl! What are you doing?” Wendl said, “I’m thinking.” And the boss said, “Can’t you do that at home?”
Averaging around 350k lines of code a year for a few years. This was mostly frontend/product focused work, so there is more boilerplate than in other disciplines, of course.
It's also important to note, the higher quality the codebase is, the less energy it takes to add to it. If you spend 50% of your time reverse engineering spaghetti code, it will be way more tiring than adding to a codebase where design is sound, code is very human readable/friendly etc.
It certainly takes a lot of energy, but why do you say it's impossible?
but I should point out that long stretches of time are different from quite (context switch free) streches of time.
I have worked on less clean codebases where I spend hours tracing state through spaghetti-like code, and there's no way you can productively code for lengths of time in those environments.
It's always better to refactor that kind of stuff ASAP, assuming the longevity of the product matters, and the refactor is a tangible improvement over the original.
How to judge whether a codebase is high quality?
Consistency of design and abstraction. Does the code use the same abstractions and design throughout? Consistency is one of the most important things in quality. How many unique concepts and abstractions do you have to learn to understand the code? E.g. in frontend context, do you use the same pattern for managing business oriented state? How is that state updated? Are those patterns consistent throughout your codebase? The biggest problem I see with the spaghetti codebases is they lack consistency in design.
Separation of concerns. What's the blast radius of any given change? If I change render logic, can it impact business logic, and vice versa? A big problem I see is that codebases do not appropriately separate these type of things out. Meaning the code is fragile and it's easy to introduce bugs inadvertently.
Anyway, I can list many points, but I'm on mobile now.
High level indicators would be: How quickly can new devs jump into the codebase? Is it easy to diagram and explain to others how the code is structured? How many bugs come out of your codebase? How quickly can you add new features to that codebase? What is the "blast radius", or is it possible to break something seemingly unrelated to a change you're making?
How do I know my codebase was good quality? I was extremely self critical when writing it and ended up rewriting it a few times before it was in a state I was satisfied with. Number of bugs are extremely low and feature velocity is high, relative to other areas of the code.
Say I had all those traits and you decided I was a 10x and now I've got my shiny label and I'm happy.
Then I come across someone else with a stricter definition and more requirements. They say I'm not 10x. Who do I believe?
Because there's no widely accepted standard, it just ends up being a game of finding the right people who like the qualities that you possess.
But the truth is there are people who are insanely productive relative to median, and 10x is just a rough term to refer to them.
I do think it's worth paying those people 2x or more over paying 1x for two median devs. The trick is being able to identify them accurately... that relies on a well honed interview. There's risk in compensating people so highly if your judgment turns out to be wrong.
Certainly definitions won't be universal, but this type of person tends to do very well regardless of the environment/language etc.
No, I'm not talking about the BS certifications where you can spend a few hours reading a book and pass a multiple choice test... but something more "elite" and well rounded to give a quality stamp of approval.
It would be a great thing if candidates could go through one process, get that stamp of approval, and receive offers from X companies.. rather than interviewing 100 times. I understand the needs of companies are individual, but most candidates who are "strong" will do well interchangeably at these companies... if it's more of a generic development role.
The difficult thing is that the industry seems very stuck on algorithm and design problems as the sole focus of judging a candidate, which are pretty easy to game (design less so than algorithms). To identify these kind of people you really need to judge real world code and productivity... large projects with more elements of design.
Beyond technical skill, how hardworking is the person? How much will they care? Personality traits like these tend to matter a lot more than specific knowledge.
Anyway... this is kind of a meandering response, but I do believe that in the future we'll have a much better system for interviewing with less redundancy and higher accuracy. The goal is to maximize correlation between performance on the interview and performance "on-the-job".
The traits I see in engineers who I consider to be 10x:
Growth mentality. Always try to do things the "right way" rather than just completing a task. Educate yourself via internet/books to understand all points of view on an issue, and tradeoffs of each approach.
Setting a high bar for your work. Never solely focus on getting the job done, always question and focus on what the best way to get the job done is.
Extremely self critical. Don't get attached to your work. Always criticize yourself and question whether decisions you made were correct.
Objectivity. Always quantify objectively to yourself why you made a given design decision, why did you name your variable X vs Y? Could you justify the merits of your approach to others without relying on subjective points?
Focus on business value. Optimize for what drives business value. Don't pursue projects that are technically interesting that don't provide long run value, for example.
Work with intensity. These people legit code 8-10 hours a day straight. They aren't coding for 30m then browsing the internet.
Never give up. Regardless of how technically challenging or impossible a task seems, they will work tirelessly to find a solution.
Self managing. Can operate 100% independently without constant manager intervention. High level direction still important to align on business goals of course.
Ownership. These people take pride in their work and feel a sense of ownership over their code. They don't need to be asked to step in when something they've worked on has an issue.
It's not about specific knowledge at all, or training.
People could learn to follow these principals, but it's much easier when it's in your nature. I have not seen anyone really change their trajectory from median to superstar before, but I'm sure it's possible with a mentality shift.