Path to being a 10x software engineer

As the CTO of Brew and together with my team, we always strive to improve ourselves and make sure we recruit the right individuals to our team. As part of the preparation for that, the term “10x engineer” repeatedly mentioned, so we tried to figure out what makes a software engineer a “10x software engineer”.
I thought I’d share some of the insights and what we’ve learned both as a business and as engineers

Below is a summary of what we think is required of, or what makes, a 10x software engineer. This will be followed over the next few months of proactive approaches to become a 10x software engineer.

First, what is a 10x software engineer?

In the last couple of years, this term has been abused and reused to mean different things to different people in different contexts.
Like most ambiguous things in life, it’s hard to define the term 10x software engineer precisely, but when you work with a 10x software engineer, you just know it.
Looking online you might find some definitions of a 10x engineer. Telling you that a 10x engineer is a developer that does 10x more in 10x less time. Some would also argue that there’s a few types of 10x software engineers, either narrow and deep or shallow and wide. I won’t go into each definition although I do think they might be correct at some level, but generally speaking, I feel this definition is too broad.
Instead, I think this is one of the cases that its easier to first define what a 10x software engineer is not.

• Seniority, or years of experience — required, but not enough.
  Experience across teams and technologies helps — but this is not a sufficient condition. As proof for that, imagine someone working in the industry for more than a decade. Does that necessarily mean they are a 10x software engineer?
• Having a lot of knowledge in specific field, does not make you a 10x software engineer. A DBA knows a lot about databases, right? A devops engineer knows a lot about the cloud, true? How about a Front-end engineer — they know a lot about reactivity and CSS and whatnot, correct?
  If an individual is not organized, has a hard time learning new things (even in their domain of expertise) and can’t communicate what they know — would their experience and knowledge really qualify them as a 10x engineers? I mean, its great if you want to become the greatest Python developer there is, but a 10x engineer, in my humble opinion, should be more than that. (More on that point later).
• A 10x software engineer is NOT a lone-rider who is best at getting s#!* done. I would argue that a 10x software engineer needs to work with and for the team. That what makes them great. They need to be able to teach others, to communicate their decision and explain why they decided on a certain approach and defend it. If they can’t teach the junior developer, it might help moving on with the roadmap and reaching deadlines, but the team as a whole doesn’t gain from it in the long run.

What makes someone a 10x engineer then?

My team and I tried to define this in terms that are actionable so that anyone who has the motivation for it, knows what they need to do to get to it.
In a nutshell this is what we got to:

What makes a 10x software engineer? a Trello board

We’ll go into details and rationale of each point later on, but before we do that, there are some things to note:

Passion

Our world (software engineering) is a vast and fast-changing world. That means you have to always be on the lookout for things as they change, new technologies, new paradigms, new methodologies, etc... But at the same time you need to be rooted enough and know your basics, things that will forever be the underlying driver of any new technology.
But to actually have the motivation to continuously learn , you must also have a genuine passion. You need to love what you do. When you do what you love, you’re not working a single day of your life, right?

A 10x software engineer is not confined to the team/company they are in right now.

A “real” 10x engineer can be taken from their current team and put in a new one. After some initial warming-up time, they’ll catch up and become 10x engineers in their new position.
If you love graphs, here’s something to visualize it:

In the figure above you can see three lines, each representing an individual arriving to a new team.

• The first (represented by the yellow slow growing line) represents an individual that is not a 10x engineer and need to learn a new stack and new technologies, so it takes them a lot of time to learn the technologies, tools, programming paradigms, methodologies etc… before they actually get to the point where they might be considered seniors in their own team.
• The second one, (the red rapidly growing line before reaching a plateau), represents an individual coming from the technology and tools that the new team uses. So they rapidly catch on. They might need to learn some of the methodologies, or understand the product and business they now work in, but they get to where they should be quite easily. We would argue that this doesn’t represent a 10x engineer, as they might be represented by the yellow line when they reach the next team.
• The last one (blue sigma-shaped line), represents the 10x software engineer — this is someone that might need some time to get into the specifics of this team and the stack they use, but grows exponentially once they do. And no matter where they land — they’ll get to it eventually and follow this trend-line.

Professionalism

In “The Big Bang Theory” there’s a scene where the group are all driving in a car when suddenly the engine shuts off.
One of the characters (Leonard) asks: ‘does anyone know anything about internal-combustion engines?’
The car full of renowned physicists replies ‘of course, its easy, basic technology’
Leonard then asks — ‘does anyone know how to FIX an internal combustion engine?’

This is a great example of the difference between knowing something in theory vs really knowing something in practice.
A 10x software engineer doesn’t only know things in theory — but instead they know how to get their hands dirty and actually perform the task. Know how things work, and how to work with these things.
The most important thing a professional knows is that there’s no “better” way, but a more “appropriate” one for the task at-hand

Now, if you would, and as promised, let’s break-down what each point means.

Skills set

Autodidact / Fast learner
A 10x software engineer doesn’t know everything in advance, but they have the will to learn. Each individual has their own way of learning and retaining knowledge. They already mastered where to look for new information (yes, you start by Googling, but now you have tons of sources, which one is the way to go? documentation? obscure blog? stack overflow?), has tools and ways to retain the information (Pocket to read later, a watch-list of Youtube videos, a pen and paper?), knows how to differentiate between what’s important and what’s too much of a niche and actually applies what they learned by trying themselves (just copy-pasting answers from stack overflow might work but you don’t really learn anything from it, do you?)

Power user
We don’t mean someone who know all the cool keyboard shortcuts and creates countless aliases to work faster. Some would even argue that it might make the developer unknowingly forget what the alias actually does behind the scenes, so when they get to a team-mates station, they don’t know what to do.
A Power user is someone who knows their tools — they know how to debug (i.e. the fact that you know about conditional breakpoints is important, how you do it in PyCharm or VSCode is something you can look-up when you need to), they know the OS and how to use it for the job at hand, they know their environment and tools and how to use them well and they have a set of tools to arrange their knowledge, tasks and work.

Methodologies
Each team works in a different methodology, and some even derive from an existing one and change it according to their needs and philosophy. But a 10x engineer knows about the different methodologies and how to use them. They don’t need to know every aspect, but they understand what’s out there.

Design, Readability, Style
That’s always one of the tricky ones. If you come from Python, try to “import this” to see the Zen of Python as a guide-line.
A 10x engineer follows common guide-lines and avoids anti-patterns and code-smells. They know how to detect one and how to circumvent them. They understand that readability counts and do their work with other people in mind (other developers, users, other stake-holders in the company?).

Communicates decisions and explains alternatives
We all encountered situations where we know that there’s a few possible ways to do something, but we feel that there’s one particular way that is more obvious or is more suitable for the task at-hand. A 10x engineer can communicate this and explain to others why they made a certain decision backed up by rationale and experience after assessing the alternatives.

Knowledge

Everything in this list can be learned and needs practice.

System Design
A 10x engineer knows about different options and how components relate to each other. They know about common designs and how to use them. They can design a component/service/system with the grand-scheme of things in mind.

Jack of all trades, master of none
A 10x engineer doesn’t need to know everything there is to know. But they know the basics just enough so they can dive more deeply when needed. Moving from devops to data to backend to frontend feels seamless and regular. A language or a particular technology are just tools. When you know the basics they are interchangeable (See how they can get into a new team and advance their knowledge quickly? Because in the end does it really matter if you are working on AWS or Azure? The basic should be the same..)

Common algorithms, data structures, design patterns
We grouped them together because they are different but still the same. A 10x engineer knows about these things so they can actually use them. It doesn’t mean they know the exact implementation of each, but they know the pros and cons, or at least know what they are meant to do, so they can look them up, dive into the implementation and use them.
Do you know about the Observer design pattern? How about TimSort algorithm? Should you use a stack or a hash for what you are working on?
This is an example of knowing the basics — of course Python and Java implement these differently, but if you know it exists its easier to look for it.

Programming paradigms
Functional? OOP? Declarative?
You can’t always decide for a team which paradigm they use, but it helps knowing the different options and sometimes use them when they are appropriate.
A 10x engineer will spend some of their time learning about these as they evolve and the ecosystems surrounding them. That way its a neat thing laying in their toolbox.

Common technologies, common tools
Cache, Relational databases, Document databases, Web servers, Load balancers, Message queues, Deployment to the cloud, Micro-services, Docker, and the list goes on and on.
Today every developer needs to know what these things are and how to use them. Even if they don’t understand every single aspect of it, they should educate themselves on what it is, when to use it and what problem(s) it solves.
Who knows? One day you might find yourself using them to solve your next problem.

Soft skills

This section is a bit trickier, because its hard to acquire these things. It’s not like there’s a book about how to gain confidence in decision making that will help you overnight.
Moreover, it’s something that connects directly to your personality and the experience you have.
I believe that its a manager’s job to provide the framework and context that will help the individual acquire these things, but they can’t be taught.

Decision Maker
Can make decisions and can defend them. Be it about the design, the code itself, the patterns used, the technology, whatever. Its true that in most cases the developer can’t just decide on these things all alone, but they can at least bring the options to the surface and decide within their own realm.

Independent
In Aristotle’s Nicomachean Ethics, it is said that the virtue is in the average, or the middle, of two vices. Too brave and you are reckless, Not brave enough and you’re a coward. The virtue lies in the middle of these two extremities.
The same goes with being independent. Too much of it and you easily get stuck on stuff that are really not important and could easily be swiped away. Too little and you ask too many questions rendering your team-mates idle from their own work just to answer your questions.
There’s good point in the middle where you are just independent enough to learn and try new things, without wasting other peoples time, or your own.

Dares to try & fail
If you are always afraid to try new things or see what will happen if.. then, you are walking in place.
This is not to say that you should try to shut down your entire production servers just to see what happens. But you need to have the confidence to try (locally or in staging) different approaches and techniques.

Creativity, resourcefulness, urge to get things done, problem solver
A 10x engineer doesn’t get stuck because someone else’s code doesn’t work or isn’t ready. They show resourcefulness to try and by-pass the obstacle and get the job done.
Sometimes this requires some creativity and sometimes its throw-away code, but nevertheless the urge to get things done makes you find ways to advance.

Team Player
Well, being a lone-wolf just won’t work for a 10x engineer. They are part of a team and they see the team’s interest in whatever they do. Which is a cool way to get to the last section..

Positioning

A 10x engineer, eventually, tries to get to the point where they are considered the tech-lead (as opposed to team lead). They want to become the point of contact (again, it doesn’t mean they know everything, but they know where to look) and be of assistance to their team-mate.
They are approachable and are willing to help others and educate others. The end-goal is to be a mentor, and pass the knowledge and expertise along.

So, finally

We believe that these are the key attributes and traits that make someone a 10x software engineer. I am sure any person reading this might add more and might contribute from their own knowledge and experience.
Please do so in the comments.

That being said, I strongly feel that most of the things in this list can be learned and acquired with practice, help of a mentor and motivation.
In future posts, we will go into the actionable items that one can pursue to become a 10x software engineer, but it helps to first know where you are going, and this is what this post is aiming for.