We’ve all heard about the 10x engineer phrase, haven’t we? Did you know that the original study back in the 1960s actually mentions a 20x difference between a great engineer and a bad one? It compared initial coding time, debugging time, program execution speed, program size…quite a thorough study, but definitely with some flaws (hey, it was the ‘60s). The general consensus is a 10x difference. I personally think that the difference can even be 20x for really great engineers, and I will explain why in this article.
Note that this difference becomes even more important if your product happens to be successful and scalable. There is nothing like code that is maintainable and scales. You can put 20 bad engineers to work on it, but they won’t achieve what a great one can. Well…actually, I guess you just can’t build a scalable product with only bad engineers 🤔. But that’s not the focus of this article.
There are already a lot of articles listing the attributes of a 10x engineer, but I will still give you my take on this first, as you can’t talk about the 20x unicorn engineer (that’s what my daughter would call them; she likes unicorns, but you can call them exceptional 😉) without agreeing on these attributes. Then we’ll talk about the additional attributes for a unicorn engineer.
Naturally, this is my personal opinion from my own experience, and you may not agree, but the eventual goal for me is to give engineers some perspective and give them food for thought on areas they can improve and that can make a difference.
I think that this is the foundation. Programmers are in a profession where many people work on the same stuff. So this point is a game changer for the whole team. Even if it’s a small hack, they build intention-revealing code that can be easily refactored, restructured or replaced.
The 10x engineers solve the problem at hand, not a fancy generalized version of it. You might think that this would go hand in hand with focus. And this point is often underrated.
10x engineers have the ability to make both quick hacks and robust solutions, and the wisdom to choose which is appropriate for a given problem. They know when to hack and when to invest in quality, and they make these choices deliberately. But their hacks are still written in such a way that they are easy to stabilize later.
They know they don’t know, but try anyway. They then iterate on their attempts until they get there. 10x engineers are in a constant learning mode. They learn languages, tools, libraries, programming styles. There is no “innate programming gift” in humans. Their talent stems from this continuous growth mindset that they possess. All their knowledge gives them different perspectives.
Engineers often loathe debugging, even of their own code. 10x engineers will just dive right in and fix those bugs with tenacity. Understand that this might not make them happy, but they know it needs to be done and it’s part of their responsibilities.
Whatever the job, 10x engineers choose the right tool for it if they figure the investment in learning the tool is worth it to do the job. This actually means that the simplicity of the solution is more important than how easy it is to find the solution. They also don’t follow any single method or methodology, but they do learn about them in case they might be useful at some point.
Average programmers will find a solution that appears to work and call it a day. 10x engineers tend not to trust their own code. They will test it extensively. The small, innocuous-looking discrepancy that good programmers might leave as is, the 10x engineers will suspect could be a hint of a greater problem, and will investigate further. They tend to do more cross-checking and sanity checking.
10x engineers are highly reliable; they have a strong work ethic and show up at meetings on time. Their understanding of time management actually helps them in release estimates, too.
10x engineers are able to understand problems clearly, break them down into hypotheses and propose solutions in a coherent manner. They are able to relay their understanding to any of their teammates. They also don’t need to have all specs written down.
They are positive, willing to go the distance to get the job done and bring their best to it everyday. Although it’s important not to exhaust an engineer with frequent urgent deadlines, sometimes this is unavoidable. When you need to ship a release out by a deadline, they will step up and get the product released whenever possible. Because they care. They also don’t let their ego get in the way of taking feedback.
Here is the last mile that, in my mind, could deepen a great engineer’s impact. None of these attributes are linked to hard skills, only soft skills. But again, collaboration is at the center of an engineer’s work, so the importance of soft skills shouldn’t be a surprise.
Note that the number of the attributes continues rather than starts over, because the 20x engineer has all of the first 10 attributes of a 10x engineer plus some more!
20x engineers have an innate skill to start with a clean slate and ability to see what is really there. By nature, people see what they are conditioned to see from their past experiences and understanding. But, somehow, 20x engineers don’t. They don’t hesitate to go back and question their own and their team’s understanding. This point could be an attribute for an exceptional product manager, too! And the worst part is once you make the effort to take a step back, thanks to their guidance, your mistake will be just as obvious to you.
They elevate their team through their understanding, knowledge and mentorship. They take genuine delight in seeing people learn. So they will, in general, favor pair programming, not because they want to mentor you, but because they feel they might learn as well. Their growth mindset becomes contagious to their team. For instance, they typically undertake all of the documentation work that is required to make the team succeed.
20x engineers are great at managing their clients or their own managers. They are more likely to understand the potentially non-obvious problems that their clients / bosses face, and offer solutions accordingly. Oftentimes, this will result in huge productivity gains for their peers, as they didn’t have to go through a lot of misunderstandings thanks to the insight of the 20x engineer.
20x engineers understand that any project (whether it’s an entire startup or inside a big company) is a marathon, and not a sprint. This means that they try to send their teammates home at the end of the day. 20x engineers tend to have interests outside of programming, to set a good example to less experienced engineers that they should keep a decent balance.
20x engineers watch how people use their software, figure out what frustrates them, and then work to eliminate their frustration. They don’t make assumptions about what people want from their software. They will try to understand their customers and their usage. They will be involved in product discussions and will challenge the product team, actually helping it, as well.
20x engineers can understand the more significant factors at play in software development, such as unique client needs, UI/UX design, budgeting, and more. This ensures they can make the right decisions at every step. They might also study the business domain they are working in, so they can express domain concepts clearly in code and connect them together to solve meaningful problems.
—
This is my list. The overall difference between a 10x and a 20x engineer is not linked to hard skills, as you can see — at least in my mind. It’s their impact on their technical team and product team that matters. We all work in an organization made of people, so let’s keep in mind that organizations are only as good as their people. We tend to forget that.
Let me know what you think! Would love to hear your thoughts about it.
Learned something? Please holding down the 👏 to say “thanks” and help others find it! If you are interested in articles about engineering and product leadership, productivity and how to scale a team, subscribe to our newsletter!
Or join our Engineering Leadership Community.
Engineering Leadership Community | Anaxi_High-quality trending articles curated by the community on engineering leadership, productivity, how to scale teams and…_community.anaxi.com
You can also check out my latest articles:
Do NOT Measure Developers - Measure Projects_Have you ever heard about teams being managed through metrics, like bug close rate or lines of code produced per week?…_link.medium.com
How to Make Estimates Finally Useful to Developers_Ask any developer to estimate how long it will take for them to finish a project. You will see the loathing in their…_hackernoon.com
Top 12 Things That Destroy Developer Productivity_A lot of articles address the role of tech leads and engineering managers. One common theme we often come across is how…_hackernoon.com
You can also follow me on Twitter to stay connected. Thank you!
Originally published on anaxi.com on October 26, 2018.