Code Monkeys & Caring
What's a 10x engineer?
The space between a mission critical engineer and a code monkey can be as thin as whether they care.
Over the years I've come to an opinion.... When people say "that person is a 10x engineer" I should interpret it as "that person cares enough that they consistently know what should be done". Getting to know these people is always a good idea.
But what is that 10x in relation to? We bandy about these massive multipliers, 10x, 100x, 10 million X... with very little regard to what we're multiplying. Let's call our baseline "1x engineer" a "code monkey": someone who does the bare minimum to get through the day. Everything above this baseline is going above and beyond.
Note: calling a 1x engineer a "code monkey" here is not a value judgment... work is work, and we should NOT expect /everyone/ to care beyond the baseline to do the job. Making ends meet trumps demanding passion of everyone doing any job. All the rhetoric around requiring passion in your job ignores reality. Code monkeys are an important part of the software economy.
If, however, you're trying to do crazy things like "disrupt a $100 billion industry with five engineers" or "fix healthcare" or whatever "moonshot" you find yourself tilting at... you kind of need people who are going to pave their own path. Caring matters when you can't break problems into bite sized tickets with well defined deadlines.
Caring means you do less of the "wrong" work. Software engineering is a form of randomized optimization. Each feature may get you closer to product market fit or push you further from it. You'd prefer to keep the features that get you closer to your goal and drop the ones that push you further away. You speed up time to success if:
you launch more "good" features than bad,
you remove "bad" features faster, or
you speed up all feature launches.
Spend energy increasing the integral over good features. THIS MAY INVOLVE LAUNCHING MORE BAD FEATURES (in the short term).
Caring is a bias toward spending more time on 1) the right features and 2) improving your second derivative: developer acceleration. Everyone talks about "developer velocity", but rarely discusses acceleration. Most teams experience negative acceleration... they slow down over time. They pay more attention to the step immediately in front of them than to the direction they're going. Having a view to your trajectory guides the random walk which is product development.
There's an analogy here to classic "algorithmic interview" performance. Candidates who code from the start of the interview have a high probability of failing it. Those who pass often take twenty minutes to avoid pitfalls and refine their approach. They spend _around half the time_ on actual implementation.
But what do I mean by caring? 10x engineers ask some very important questions, notably:
Why does this problem exist?
How can I master the discipline of solving this kind of problem?
Caring is a meta-behavior. It's tackling the system of behavior itself instead of just its byproduct (the marginal puzzle at hand).
If you've ever seen a manager, blog post, etc. wax eloquent about 10x engineers just working harder, know that they're misattributing perceived productivity. Sure, working harder gets you further. What they're witnessing, though, is that these 10x engineers are producing less waste. When you work marginally more on the wrong things, that marginal work is wasted. When you care enough to root-cause customer issues, systemic outage causes, etc., you spend less total effort to do more.
Spending more hours is at best a linear increase in work done within a day. Caring about how you spend a given hour and working to make it more effective is how you 10x your productivity. Debating the effectiveness of crunch mode and overtime are independent of this observation. Tl;dr crunch mode seems to be a more expensive way to get the same or worse work product. Considering some single-digit "work hard multiplier" is its own can of worms.
The space between a mission critical engineer and a code monkey can be as thin as whether they care.
But how do you learn to care? How do you recognize a caring engineer at hiring time? How do you get an engineer to care more?
These deserve essays of their own. Stay tuned for more.
P.S. I'd say there's also a 10x bonus for convincing other people to care. Caring can be infectious. Caring and convincing others to care are how we get to the absurd/mythical "100x engineer".