Better engineers than the typical engineer by a factor of ten. They operate like a one-man army and produce more value faster than an entire staff of junior engineers.

But how is that possible? The more the better, right?

I can testify that 10x engineers actually exist because throughout my time as an engineering lead at Netflix and Amazon, I worked with everyone from new grad interns to principle engineers (L7 and higher at Amazon). I can also say with certainty that they aren't:

• typing 10x faster
• working 10x the hours
• writing 10x more code

In fact, 10x engineers might type at half the speed, work half the amount, and spend more time DELETING code rather than writing it.

The main mentality distinction between top engineers and less experienced engineers. They know how to prioritise and apply the appropriate tools and questions. Even those with no technical background can learn non-coding-related skills.

In this essay, I highlight three mistakes that novice engineers frequently make and how a senior engineer would approach the same issue, with quite different outcomes.

1. Not investigating tooling enough

"If I had 8 hours to chop a tree, I'd spend 7 sharpening my axe," stated Abraham Lincoln once.

A young engineer will hack for eight hours with a blunt axe. The senior engineer chooses the ideal chainsaw for a full hour.

and took five minutes to cut the tree.

I frequently observe junior engineers make the error of diving right into coding. They attempt to adapt only the tools they are familiar with to every circumstance.

They almost ever consider other options, let alone whether the task can be completed with no code at all!

The difference between working for weeks on a task and accomplishing it in 10 minutes is the appropriate instrument. The 10x difference results from this.

For instance, creating a webpage
I recently had the pleasure of making a wager on who could create a personal website faster with a junior engineer.

In two weeks, the recent graduate wrote more than 1000 lines of code. After two weeks, they hadn't even finished!

I put in a full day, produced zero lines of code, and barely even broke a sweat.

Note how this engineer's strategy omitted a number of crucial details. To begin with, they never brought up:

• requirements — no mention of whether SEO, commenting, or having pre-built templates was important.
• alternative tools — they just knew React + AWS and stuck with it.

Imagine trying to rebuild commenting features from scratch. Or making sure SEO worked properly. Each of those features is a team’s worth of work to implement properly. No wonder they never finished!

2. Not asking for help

Even though it's pretty straightforward and simple to correct, this one has taken up so much time that I feel compelled to bring it up.

A senior engineer is viewed as being like a lone genius by some junior engineers. They'll find a solution if they keep working on the issue.

But this kind of thinking is quite naive. The context that they were missing—information that they were unable to infer on their own—is frequently what made the difference.

Therefore, instead of just seeking assistance, they spend hours poring through the code base and repeatedly reading the same lines of code, when a quick question to a teammate would have fixed the problem in a flash!

Sometimes it is obvious that further background information is required before moving forwards. For instance, it's frequently unclear:

• why the code base was structured the way it was
• which API to call from another team
• how deployments work

These are examples of contextual situations where you’re better off asking for help than digging any further into the codebase. Don’t be afraid to ask for help!

3. Not delivering business value

Investors are 10x engineers' primary role.

They realise that the time they put into their work is an investment, and that the return on that investment must much outweigh the time invested. They are aware that time spent on one feature translates into time not spent developing another feature.

They are aware that programming serves as a tool to achieve a goal—a commercial goal. And even better if they can complete their task without using any code! It's a win-win situation because there's less code to write and maintain.

Many rookie engineers, in my experience, overlook these commercial objectives. Some instances:

• “There’s this new technology out that’s really cool. Let’s spend five days integrating this into the website” (no alignment with product)
• “I don’t like the way the code is structured. Let’s spend next sprint refactoring” (opportunity cost — is this a better use of time than building revenue-generating features?)
• “This platform is so legacy — let’s migrate to a new platform” (does the migration help you move much faster, or is it just an incremental improvement?)

It’s this math that leads to a 10x engineer. If a junior engineer spends 2 hours working on a complex feature that doesn’t increase revenue, but a senior engineer spends 1 hour on a simple copy change that 5x’s the revenue, we get a 10x improvement in productivity.

Final Thoughts

The "soft skills" (non-technical skills) are what separate the best engineers from the worst. An engineer's 10x skills are rendered useless if they avoid all of the aforementioned faults but are unpleasant to work with.

You put a lot of effort into becoming an engineer. Not being a jerk is lot easier than engineering. Don't let your ego cause your hard effort to be wasted. And keep in mind.