How to become a “10x engineer”

Eng Technical Track 7 Minutes

“10x engineer” is a controversial term that may elicit negative reactions from many. Controversies aside, there are indeed huge variances in productivity among software engineers, including those with comparable amount of experience. It’s a worthy endeavor to strive to become a 10x engineer with an extraordinarily high level of productivity and impact.

  • 10x engineers are not “lone wolves”/”brilliant jerks”, as some of the misconceptions may lead you to think what “10x engineer” means.
  • The studies that supposedly demonstrate that the best programmers write code 10-20x faster than the weakest ones and debates about the validity of the conclusion are not that interesting. The reasons are simple, including:
    • How fast an engineer writes code (even with the qualification “high-quality”) is at best a plausible indicator for their productivity. It’s actually not that meaningful, and is frequently misleading, as time spent on coding is just a small part of the job of experienced engineers who really create value. 
    • Frequently a great engineer can come up with a good solution that takes much less code to implement than another engineer’s solution to the same problem. How much do you still think the ability to quickly crank out a lot of code matters (even if it’s “high-quality” code)?
    • The best engineers are great at finding good problems to solve, and quickly ruling out problems not worth solving. Can you write code faster than not writing it at all?

There are actions you can take everyday to get closer to being a “10x engineer”. In a reasonable number (say 5-10) of years, with deliberate and well-targeted efforts, you may get there. We’ll provide some pointers in the rest of this article to guide you. Obviously it takes books to cover it in depth, but we believe many engineers will get useful insights from this article and find the investment of 5-10 mins of their time worthwhile. 

The main points in blog General advice for engineers are very applicable here. In particular:

  • Keep learning and learning deliberately.
  • Maximize your impact.
  • Minimize the overhead you cause others and become “fire & forget”.
  • Increase your network and build a support system.
  • Internalize that technology is 90% about solving problems for people.
  • Work on your soft skills – communication, interpersonal, influencing skills in particular.
  • Focus more on fundamental/”horizontal” skills (vs “vertical” skills).
  • Manage your time wisely – defragment your time, minimize distractions, and focus.

Anything above makes you believe 10x engineers are “lone wolves”/”brilliant jerks”?

We’ll talk about “technical skills”, as we know many engineers are eager to see more “real stuff”, and less “fluff”. Bear with us, though – we’ll push on some of the “fluff” a bit more before diving into the “real stuff”, as the “fluff” actually matters much more than many think. In fact, much of it is not fluff at all if you really understand them. Also we’ll delve more deeply into some of them in future blogs (as they’re again much more important than many may think). 

  • Manage your time wisely – defragment your time, minimize distractions, and focus. 
  • Internalize that technology is 90% about solving problems for people.
    • Technologies are valuable and relevant only to the degree that they can solve meaningful problems for people and add meaningful value, at reasonable cost.
    • Don’t get fixated on technologies/technical aspects of your work alone. Learn to pick the right problems to solve, understand whom you’re trying to solve the problems for, frame the problems properly, and come up with good solutions. 
    • For your work to be truly productive and impactful, you need to be “building the right things” (before thinking much about “building things right”). The blog – The problem is the product has good pointers, and we’ll delve into this and related topics in future blogs too.  
  • Work on your soft skills – communication, interpersonal, influencing skills in particular. 
    • Almost all software engineers work with people, as part of a team. Even in the rare cases in which you manage to build a useful piece of software as a solo effort, there is little chance you can achieve meaningful success with your product unless you can at least work with your users. Making a conscious effort to gain more awareness of the human elements of everything we do, work on the “soft skills”, and get better at communicating with, influencing, motivating, and working with people in general will make your work much more productive and pleasant, and yourself a better person at the same time. 
    • A few great books to read to start with:
  • Maximize your impact. Great engineers not only tackle with gusto critical issues or core parts of a high-impact product, but also they take their own initiatives to seek out high-impact work, particularly those with “multiplier effect”, for example:
    • Catch early on flaws in architecture or major design/implementation decisions made by the team.
    • Find or build a framework or tool, and influence the team to adopt it to improve the productivity of multiple people on the team.
    • Identify meaningful process improvement and work with the team to implement it. 

Finally on to “technical skills”. Engineers expecting mention of latest/greatest/most in-demand technologies will be disappointed, though. They are interesting to some degree, but technologies come and go, and chasing them won’t make you a great engineer. It’s important to focus more on “horizontal skills”, and pick up fundamental insights and techniques that help you build software much more productively. 

Software is notoriously hard to build. It’s helpful to reflect on what fundamentally makes software hard to build:

  • complexity 
  • changes

Most of the fundamental and valuable techniques and insights in software engineering help you (and your team) tackle these 2 challenges. Among them, the following are particularly important for aspiring software engineering to learn and internalize over time. 

  • Keep it simple
    • Use the simplest design/implementation that can possibly work.
    • Minimize speculative work. Avoid premature optimization.
    • Code that you avoid writing is the best code. 
  • Divide and conquer
    • Decompose your system into subsystems.
    • Decouple the subsystems, and minimize dependencies among them. At minimum, minimize hidden dependencies.
    • Repeat these to further decompose the subsystems, and keep going. 
  • Enforce “separation of concerns”, and separation of interface from implementation
    • Model the system/subsystems well, with reasonable abstractions and reasonably well-defined behaviors/interfaces. 
    • Make interfaces as small as possible, and avoid exposing implementation details.
  • Design for changes/encapsulate what may change
  • DRY – don’t repeat yourself. Eliminate duplication.
  • Optimize for quick time-to-result and quick iterations.
    • Deliver incrementally and iteratively.
    • Release early and often. Deliver values to users as early as possible. 

They make it feasible for mere mortals to manage the otherwise intractable complexity of software, and reason about complex systems. Due to the complexity of software and limitations of humans, almost all non-trivial software with practical values are built by a team, and these principles and techniques are critical to enable a team to be productive and delay the point of diminishing return from adding people. Furthermore, they help you focus on what will likely produce the most value, and enable you to deliver value as early as possible, with the confidence in your ability to deal productively with changes that will inevitably come as the impacts of potential changes are reasonably isolated.

Some of the principles may appear to be conflicting with each other, and they do. After all, much of building software is about managing trade-offs. To become a great engineer, you need to internalize these principles/techniques among many others, how to apply them, when to apply them, when to optimize for which subset of them against the rest.

How to pick up/internalize these principles/insights and relevant techniques?

Leverage good tools and build up your own toolbox. Good tools can be a multiplier for your productivity. Important to find a good set of high-quality tools, get good at using them, and make an ongoing effort to maintain your toolbox. Btw, nostalgia aside, it’s a pity that many engineers nowadays don’t appreciate as much the value of good old tools – command line tools and plain-text. 

Keep expanding your knowledge/skill portfolio and become a specialized generalist. 

  • While we keep emphasizing the value of focusing more on “horizontal skills” (rather than “vertical skills”), broad knowledge & exposure to many technologies/”vertical skills” do make a difference, especially if you’ve been improving on your “horizontal skills” too. 
  • These in combination with “specializations” will amplify your productivity and impact, especially when you apply them to solve the right problems. “Specialization” includes specialization in certain problem domains, in addition to specialization in technologies. Broad knowledge in and deep understanding of a certain problem domain, in particular, can be a huge leverage in your endeavor to solve problems in the same domain. 

In closing, we’ve provided some pointers at a high level to guide you in your journey to become a 10x engineer. We’re necessarily only scratching the surface, and will expand on some of the topics in the future. 

Published by AndrewDong

Published

One thought on “How to become a “10x engineer””

  1. Pingback: 10x Engineer - The Root Cause - Talent Whisperers®

Leave a comment