I used to assume that the "10x engineer" was 10x faster at the programming/typing part, but it turns out it's more like identifying the 1/10th of the work that actually matters and just do that efficiently. It is also true that there's a lot of experience in both the identification of that 10%, and the efficient execution of it though.
Side note: I have also met a few flat out amazing, natural programmers. These people can also be 10x as productive, but it's in a pretty specific way that should probably just be considered an outlier. My feeling is that the main way for the rest of us to achieve that level of productivity is gain experience, do things simply and efficiently, and learning how to focus on the things that matter.
the 10x programmer is by definition an outlier
1. There usually are just a few critical pieces to any project. You should try to start with those and get them locked down first. These can be critical because they are either technically unproven or just plain difficult. Once you know the hard stuff is handled then you can fill in the easy stuff from there on out. (You'll also feel less inclined to fancy-up the easy stuff, in my experience. That's another source of trouble).
2. Use quality tools, become an expert with them, and hold on to them as long as you can. What does quality mean? To me: reliability, stability, and efficiency of both my time and the machine's time. Knowing how to do something because you've done it before, seen the problems and worked through them, and come out the other side, is _huge_. Rarely rarely rarely, a new technology comes along that overwhelms the advantages that hard won experience provides, but it's super rare. This is a whole topic in itself, but in my 20 years the list of situations in which something new clearly brings enough benefits to switch are surprisingly rare. Off the top of my head (and just to make everyone mad in one easy sequence): moving to Java from C/C++, Hibernate ORM instead of endless hand crafted SQL, S3 instead of a probably-about-to-be-full attached volume, Heroku instead of running my own machine, Unity instead of my bad custom game engine, and most recently Flutter instead of native Android/iOS (although this one is still early days).
3. Be honest about what you're actually spending your time on, and optimize for that. A lot of the fancy programming languages of recent years have been spending huge amounts of time optimizing what, for me, weren't big usages of my time. I realize this is vague, but an example for me might be Scala. The stuff that they were improving looked fancy in examples, but it didn't make a material difference to me (as a Java programmer) in what I actually spend time on. It also came with a bunch of downsides, which is itself worth an entire post.
4. Don't be afraid of simple looking code. It might be slightly embarrassing to check in, but it's probably going to be clear how it works to you any other other person who needs to read it in the next few years. The urge to appear smart in the way your code looks can be deadly.
5. Be specific about the upsides you expect when examining a new technology. Are you looking to work faster, are you looking for performance in a specific category, etc. Failure to properly define your criteria leads to adopting things that are a bad fit for your situation (helllooooooo microservices) or at least provide minimal benefit in return for the _huge_ expense of throwing out experience in another technology.
I'm pretty sure there's lots more examples, but that's all I got at the moment. I will add more if I think of it. I guess this should all be a big blog post at some point as well, if it's something people find interesting.
Point 2 (and 5) is probably one of the biggest things I think about a lot these days. Most of my tech stacks are relatively tried and true, with the exceptions of Netlify and GCP. Where it's possible, I will generally try to put a $10-20 dollar SaaS product instead of code. That comes with counter-party risk, but I trust Pingdom more than I would my own notification servers.
When I wrote this article, I struggled with explaining how my thoughts of what a 10X engineer changed over the years. I recognized people would yell 10X != memorization, but the compound effect of working (and learning) without friction (in this case, human memory. in many other scenarios, technical debt) leads to exponential advantages.
- Getting the requirements right. This by far has the most impact on effectiveness
- Reducing friction. Simple things like proficiency with high quality tools, smooth and fast builds, clean logs, easy ways to generate and analyze core dumps, accumulate to produce an outsize effect on productivity.
- Uninterrupted, substantial blocks of focused time. It is staggering how easily chat, email and meetings can destroy productivity.
Quick tip: For people who work in a company where they don't necessarily have control over their own time: schedule the living out of your calendar. Book endless meetings with other programmers, then just sit there and do work. "Q2 Backend Architecture Review: 4 hrs" can just be a few people sitting in the meeting room programming. It's crazy the power of blocked out time on your calendar to a manager who otherwise sees an empty day.
Another way I've tried to tackle this is on day 1 of a job - I've blocked out a huge chunk (4 hours) of my daily calendar of "Coding Time - No Meetings, No Slack, No Email" before anyone could tell me no.
Open plan, with 2nd line support talking to customers right next to developers.
My team has coordinated it so we spend mornings working independently on the most important things we need to get done. Only the afternoon is open for meetings. In those meetings we often identify things that we will each work on independently the next morning. This better planning leads to more focus and the reduction in distractions leads to more productivity.
Emergencies are exceptions, but it's amazing how rare those can be if everyone has a decent amount of time to handle their most important things every day. Also, many people are not well organized and this small amount of organization makes a massive difference.
I don't think I quite captured everything, I might take another shot at this again sometime.