10x Engineers: the Myths and Why You Don’t Need to be One

7 min readMar 6, 2020


Everybody’s talking about 10x Engineers. Do they even exist, or is this just imposter syndrome? Let’s break it down.

Who is a “10x Engineer”?

Is it someone who writes thousands of lines of code every day? Is it someone who pushes new product features overnight while being heavily caffeinated? And why is this idea of a “10x Engineer” pushing more people towards experiencing Impostor Syndrome at the workplace?

In this article, we’ll debunk the myth of the “10x Engineer” and talk about the infamous Impostor Syndrome.

For more thoughts on the “10x Engineer”, see Codementor’s previous article with Moz founder, Rand Fishkin, here.

I came across a Twitter thread the other day which really intrigued me. This thread spoke about what a “10x Engineer” is supposed to be like. 🤔

Here’s how it started off:

What intrigued me even more was to see how many experienced engineers, Google Developer Experts, engineering leads, and other professionals on Twitter were getting pretty heated about the idea of a “10x Engineer”, according to this particular thread.

Let’s find out why, take a closer look at the 11 points made in this Twitter thread, and discuss why the idea of a “10x Engineer” could have harmful effects for employers and employees. I’m also going to be talking about some key takeaways in this article.

Disclaimer: This article only holds my views about the “10x Engineer” and is in no way meant to disrespect anyone or their views.

1. “10x engineers hate meetings.”

A lot of important decisions get made in meetings. As an engineer, it’s important to be in a cross-functional team, where you not only interact with other engineers, but you also talk to designers, backend developers, product managers and other stakeholders in the company. This allows you to get a better idea of the product you’re working on and the direction in which it’s heading.

I know everyone hates meetings, but it doesn’t mean they aren’t productive. 👨‍💻

Takeaway: Attend meetings. Not all of them will be productive, but for the ones that are, you’ll learn a lot from people in other company departments. Take it all in and absorb as much as you can.

2. “Timings in the office for 10x engineers is highly irregular.”

This could potentially give “10x engineers” an excuse to not be on time. I personally work until 2AM at night, but I get my 6 hours of sleep and I’m in office at 10AM. Also, I love working around other people. I get to learn a lot from people with more work experience than me.

Takeaway: Being open to learning stuff from your colleagues is something no one in a workplace should neglect. Don’t limit yourself to your desk in the office. Try to be on time, but most importantly, maintain a good balance of work and sleep. Late-night coding isn’t good for you if you’re not meeting your personal sleep requirements.

3. “10x engineers know every line of the code that has gone into production.”

When QA does alert them of an issue, engineers typically solve the problem using their skills and the knowledge they have of the codebase. Some issues could take hours, some could take days. But not every issue can be fixed in hours; it is simply not feasible in real life.

Takeaway: Know your codebase well, but don’t put too much pressure on yourself to know every line of code. You’ll get more familiar with it over time. Fixing bugs and errors is also something you’ll get better at with time.

4. “Most of the 10x engineers are full-stack engineers.”

We wouldn’t have any front-end engineers, UX engineers, or anyone who’s specialised in turning good designs into UI code if all “10x Engineers” were full-stack engineers. Sure, full-stack engineers are great, and I know a few of them who are skilled at multiple things in a product, but this whole idea of a “10x Engineer” rarely doing any UI work doesn’t work out in any organization.

UI work is just as important and it comes with its own challenges.

Takeaway: If you’re a full-stack engineer, then that’s fantastic. Work on all the things that you love to work on. If you’re a front-end engineer, that’s awesome too. Focus on your UI coding skills and be great at that. It is up to you whether you want to be a specialist in one particular set of skills, or want to experiment and work with multiple skill sets.

5. “10x engineers can convert thought into code.”

The idea that one could convert “thought” into “code” could be demotivating to junior engineers, who are just getting started in their fields. This is exactly the kind of pressure that engineers should avoid putting on themselves.

Additionally, while it is a good skill to be able to build product features quickly, it’s also important to remember that this sort of skill is honed over years of working as an engineer.

Takeaway: . Break down the task of building the feature into smaller bits, talk to your manager and set some real expectations about the deadline of the product feature. Doing this not only increases the amount of respect people have for you in the workplace, but also makes sure that you aren’t setting any unrealistic expectations around deadlines.

6. “10x engineers rarely look at help documentation.”

The whole purpose of having documentation around something is for engineers to look at it. It doesn’t matter if they are junior, intermediate or senior, every engineer looks at documentation from time to time. Relying entirely on memory power is never a good idea.

Takeaway: You’re a human engineer. You’re definitely not a robot. You do not need to have any documentation memorized. As an engineer, it’s always a good idea to know how to frame the question for your problem, rather than just having the solution to your problem memorized itself. Know how and what to ask, and you shall receive answers.

7. “10x engineers are always learning new frameworks, languages.”

This tweet does have some good points. It is important to learn new frameworks and languages, but the part where “10x Engineers” do that “ahead of everyone in the company” could potentially breed negativity in the workplace.

Instead, if there is a new framework that some engineers are required to learn in the organization, and this supposedly “10x Engineer” has already learnt it, is it the duty of the “10x Engineer” to setup a workshop or a hackathon where he/she helps train fellow colleagues in learning the framework?

Takeaway: Go ahead and learn that new framework or language that everyone is talking about, but stay humble and aim to help coach people who are new to it.

8. “10x engineers are poor mentors.”

This back to the same point I’ve made for #8. Your job as an engineer is not just to push thousands of lines of code. You have to be able to communicate with your team well. But it is not a great idea to promote bad teamwork by insinuating that a “10x Engineer” is a one-(wo)man army.

Any good product in any big organization is built with a good team of people. These people have great teamwork and chemistry amongst themselves.

Takeaway: If you’re working with someone who needs your help, you need to be able to mentor them. Again, this ties into the whole idea of making the team better as a whole, rather than doing everything yourself. Take the time to discuss ideas with everyone in your team and, I promise you, it’ll pay you back well in time.

9. “10x engineers don’t hack things and know how the code has to evolve.”

While it is a fantastic idea to write code that’s well-structured, you cannot know how your code might evolve. There could be a new framework that you might need to use that could potentially change the entire structure of your code. I’m all for writing quality code, but I’m not sure how much I agree with knowing exactly how the code has to evolve.

Takeaway: Write quality code, have a good mental model of your overall code structure but be prepared to incorporate new frameworks and technologies into your existing codebase.

The Dreaded “Impostor Syndrome”

If you’re a junior engineer, and you’ve just begun your new role at your company, I’m sure some of the following thoughts might have gnawed at you at some point:

  • “I’m not good enough.”
  • “I was hired by accident!”
  • “How will I ever be as good as my colleagues here?”

Guess what? I also felt that way in my first engineer role, and you’re not alone. In fact, studies show that even senior engineers have felt that way, even after many years of experience! Shocking, isn’t it?

Now, I’m not sure why most engineers, myself included, feel this way — but I do know how I’m tackling it. The solution is quite simple: don’t let yourself obsess over whether you were hired by accident or whether you’re good enough for the job. Let the person who hired you do that.

What this means in simpler words: if you were hired for the job, you’re good enough for the job. There’s absolutely no need to ruminate over whether you were “hired accidentally”. The hiring manager saw something in you that he/she liked and decided you were fit for the role, period.

Stay focused on doing your job well, and you’ll do just great. There’s a lot of room to learn when you’re new to your field of work, especially when you’re working with engineers who are more experienced in the field.

However, this shouldn’t be a gateway for self-doubt, but rather it should be seen as an opportunity to grow your skills in your new role.

“If you’re the smartest person in the room, you’re probably in the wrong room.”

This post was written by Bapusaheb Patil and originally published on the Codementor blog