Why You Don't Need to be a 10x Engineer

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? Also, 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.)

The Twitter Thread

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.

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 don’t see why this is seen as a negative thing. An engineer should have good product knowledge. It’s definitely not advised to just push thousands of lines of code and call it a day.

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.

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.

As tempting it might be for some engineers to need some privacy when working, it doesn’t mean all engineers are like that. If that were the case, we’d have a lot of empty offices during the day. 🤷‍♂️

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.

For starters, what does my laptop screen background have to do with anything? Here’s what the home screen looks like on my laptop right now:

Additionally, the keys that are worn out on my laptop are Control and Tab, because of the tab switching feature in macOS and Chrome, which I frequently use to Google for answers when I’m stuck with a coding challenge. (I’m a 1x Engineer. 😉)

Takeaway: Set up your devices and optimise them for your highest productivity. Ignore all the other norms, and the “you should use this” and “why aren’t you using this?” suggestions. Do take in good advice, but at the end of the day, figure out what works best for you.

Most of the engineers I know rely on their problem-solving skills and “thinking-on-their-feet” skills, rather than relying on their memory power. This Tweet implies that 10x Engineers have incredible memory power.

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.

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.

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. The whole idea of “drink lots of coffee and build me this feature in four to six hours” is a toxic way of pressuring engineers to get work done faster.

Besides, too much caffeine is bad for your health! 🙅‍♂️

Takeaway: You won’t be doing anyone any favors if you caffeinate yourself and have a burn out; that only slows down your productivity. 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.

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 engineer. You do not need to have any documentation memorized. You can look stuff up on the internet, because I assure you, that’s what even the most experienced engineers do. But 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.

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, it is the duty of the “10x Engineer” to setup a workshop or a hackathon where he/she helps train fellow colleagues in learning the framework.

After all, which engineer doesn’t love a hackathon? 😉

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.

This Tweet brings me 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.

I assure you, that is not the case. Any good product in any big organization is built with a good team of people. These people have great teamwork and chemistry amongst themselves.

Additionally, if “10x Engineers” are “poor interviewers”, then that just shows they are bad at communication and presenting 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.

While it is a fantastic idea to write code that’s well-structured, you cannot know how your code might evolve. There might 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.

On another note, writing a well-detailed design document is an absolute must if your team is planning on expanding and taking in more engineers. It makes the onboarding experience for new engineers easier.

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. Also make sure you write good documentation for your code so that new engineers who will eventually work on the product don’t have any problems in code comprehension.

Skilled engineers, more often than not, are the ones who job hunt or move out of the company. Why? This could be for any of the following reasons:

Their current work is not challenging enough and they want to explore new challenges in other organisations that might help them grow as an engineer
They aren’t happy with the way they are being compensated for their skills and are looking for higher salary packages that reflects their skills
They might find the current workplace toxic, i.e., they might have a boss who wants them to be a “10x Engineer” 😉

Also, if you’re a hiring manager and you happen to come across an engineer who dislikes meetings, training, or anything that has to do with helping his/her team, run in the opposite direction. This is a sign of a person with self-interests so deep that their skills will benefit no one apart from themself in the long run.

But under no circumstances should you “hold onto them” or “celebrate them”. 🙅‍♂️

Takeaway: If you’re happy in your current organization, that’s fantastic, but if any of the above-mentioned reasons seem to resonate with you, I’d suggest job hunting and finding a job where you’ll be happier and more fulfilled. Find the right job for yourself, participate in meetings and training, and grow as an engineer while also helping your team grow with you.

Now that I’ve talked about this particular Twitter thread, let’s move on to another problem that a lot of engineers face at least once in their careers.

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.