The best engineers are 10x better than an average engineer. Like a one man army, they deliver more value, faster, by themselves, than a team of junior engineers combined.

But how could that be? Isn’t more always better?

In my time as an engineering lead at Netflix and Amazon, I’ve worked with both new grad interns all the way up to principal engineers (L7 and above at Amazon) and I can attest that 10x engineers do exist. I can also confidently say 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 difference between the best engineers and junior engineers boils down to an issue of mindset. They use the right tools, ask the right questions, and know how to prioritize. Skills that have little to do with coding that even non-technical people can develop.

What separates the best engineers from the average ones are (surprisingly) the non-technical skills.

In this article, I discuss 3 common mistakes junior engineers make, and how a senior engineer would tackle the same problem differently — leading to vastly different results.

2. Not investigating tooling enough

Abraham Lincoln once said “If I had 8 hours to chop a tree, I’d spend 7 sharpening my axe.”

A junior engineer will spend 8 hours chopping with a dull axe. The senior engineer spends an hour picking the right chainsaw.

And 5 minutes cutting the tree.

A common mistake I see junior engineers make is that they dive head-first into coding. They stick with only the tools they know, and try to fit it for every situation.

If an average engineer only knew how to use a hammer, they would also use it to dig a hole.🙄

They spend almost no time looking into other alternatives — or whether it’s possible to do the job writing 0 code at all!

Using the right tool is the difference between laboring for weeks, and finishing a task in 10 minutes. That’s where the 10x difference accrues.

Example task: Building a website
I had the pleasure of taking a bet with a junior engineer recently on who could build a personal website faster.

The new grad spent 2 weeks, and wrote over 1000+ lines of code. And they didn’t even finish after two weeks!

I spent 1 day, wrote 0 lines of code, and didn’t even break a sweat. You can see the result of my home page here.

When I asked the junior engineer to explain how they approached this, it became clear why they took so long to finish:

“Well I learned how to make a React app in school, so I just created a website from scratch with that. But I also didn’t know how to deploy it. So I thought I had to write a custom deployment script on AWS but got kinda confused by the console. What’s the difference between the micro instance and the large one again?”

Note how this engineer’s approach missed several key points. For starters, they never discussed:

• 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

This is a really simple one that’s easy to fix, but has caused so much wasted time that I have to mention it.

Some junior engineers have this misconception that a senior engineer is like a lone genius. If they keep at the problem, they’ll eventually get a solution.

But this is a rather naive way of thinking. A lot of times the difference is that they were missing context — information that they couldn’t possibly deduce themselves.

So instead of just asking for help, they stew over the code base, looking at the same lines of code over and over, when a 5 minute question to a teammate would have resolved the issue instantly!

A less experienced engineer who knows how to ask for help will always beat a more talented engineer who never asks for help.

Sometimes it is clear that extra context is needed in order to continue. For example, it’s often not clear:

• 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

10x engineers are investors first and foremost.

They understand that their work is an investment — and the payoff of their investment has to vastly outweigh the cost of the time spent. They understand opportunity cost: time spent building one feature means time not spent building another feature.

Engineers must weigh opportunity costs — “Of all the features you could build — is this feature the best use of your time?”

They understand that code is a means to an end — a business end. And if they can achieve their goal with no code, even better! It’s less work to write, and less code to maintain — a win-win situation.

I see a lot of new engineers lose sight of these business goals. Some examples:

• “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:

1/2 the time spent on a feature that generates 5x the revenue = 10x value delivered.

Final Thoughts

Non-technical skills (the “soft skills”) are the difference maker between the strongest engineers and the weakest. If an engineer avoids all the above mistakes, but they are difficult to work with, their 10x skills are nullified.

You worked hard to become an engineer. Engineering is way harder than not being a jerk. Don’t let your hard work go to waste because of your ego. And always remember:

Engineer’s have to deliver value first and foremost.

Want more career advice?

Join 2600+ people on my newsletter reading new articles every Tuesday.

Connect with me on LinkedIn and Twitter.

Find the rest of my socials here. Cheers!