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.
10X 엔지니어와 주니어 엔지니어의 차이는 마인드의 문제
- 10X 개발자는 올바른 도구를 사용하고
- 올바른 질문을 하고
- 우선 순위를 정하는 방법을 알고 있다.
//코딩의 문제가 아니다.
1. 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.
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.
올바른 도구를 사용하는 것은
몇 주 동안 수고하는 것과 10분 안에 작업을 완료하는 것의 차이 정도 벌어진다.
여기서 10배의 차이가 발생한다.
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 she 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.
Note how this engineer’s approach missed several key points. For starters, she 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 she 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 formost
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 5 days integrating this into the website” (no alignment with product)
- “Ugh I don’t like the way the code is structured. Let’s spend next sprint refactoring” (opportunity cost — there could spend this time building revenue generating features)
- “This platform is so legacy — let’s migrate to a new platform” (does the migration help you move significantly 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.
생성하는 기능에 소요된 시간 2분의 1, 생산성 5배의 수익 = 10X value 전달한다.
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.
엔지니어는 그 무엇보다도 가치를 먼저 전달해야 합니다.
Refer : Micheal Lin
