Will the real 10x-ers please stand up
There’s this pervasive archetype of a “10x Engineer” as a person who has meticulously optimized every aspect of their coding workflow to reach unimaginable levels of productivity. Engineering influencers like to talk about flow states, chording keyboards, and micro-dosing LSD.
Not wanting to get left behind I went on a personal journey of what, in Silicon Valley terms, might be considered ‘self development’. I switched all of my IDEs to vim keybindings, created template scripts to automate repetitive tasks, and even tried a nootropic supplement that promised to improve my ‘logical problem solving’. It all sounds silly, but so do the habits and routines of Olympic athletes. Maybe achieving true greatness in a field requires some amount of eccentricity.
Or, as I quickly realized, maybe it doesn’t.
What if Software Engineering were more like Actual Engineering
In the real world, the most experienced (and highest paid) software engineers are often the ones who write the least code. A day in the life of a typical senior-level engineer involves meetings, code reviews, timeline planning, design documents, and mentoring. By the strictures of programming dogma these activities would all be classified as ‘distractions’ that break flow states and get in the way of productivity.
This is, of course, ridiculous. I don’t think the structural engineers who build skyscrapers gripe about how they have to plan and document and review blueprints before getting to the real work of bolting I-beams together. Collaboration is productivity, just not the type of productivity programmers tend to strive for. Our vision of productivity is often to just get something built quickly and see what happens. But, given the power software has to shape the world, the mentality of ‘move fast and break things’ is becoming increasingly less endearing.
Positive impact only matters if it’s enduring. An engineer who optimizes their individual workflow at the expense of teamwork does not leave a lasting legacy. If a single meticulously-efficient “10x” programmer writes the lion’s share of your codebase and then leaves the team, you’re hosed. On the other hand, if an engineer fosters a collaborative environment and keeps everybody aligned it’s not hard to imagine that their total impact might actually exceed that mythical 10x goal.
So when I fell down the rabbit-hole of programming life-hacks, I was optimizing for the wrong thing. Even if I became very slightly better at programming, it had no impact on my actual job.
An Inconvenient Truth for Introverts
I’m an introvert, and given the demographics of programming posts on Medium there’s a good chance you are too. Being an introvert is of course different from being socially awkward, although you and I might fit that bill as well. Hollywood’s portrayal of nerdy programmers is often totally over-the-top, but it didn’t come from nowhere. Programmer culture seems driven by the idea that “the meek shall inherit the earth”. This is where our belief in meritocracy comes from: unlike other jobs it doesn’t matter if you’re beautiful or funny or popular, it only matters if you can write good code, right? … Right?
Not exactly. Our job isn’t to write ‘good code’ — it’s to create products that meet people’s needs. Being good at that job is exceedingly difficult if you never talk to people. And, even if you make efforts to reach out and start discussions, they’ll probably be fruitless without at least a cursory effort at being respectful, personable, and pleasant. Extrapolating this out, being funny and popular actually are helpful skills for a programmer to have (beauty is optional but basic hygiene is nice). So, our attempt at a coding meritocracy was never even a good idea in the first place.
Luckily, it’s not all bad news for us introverts! As Susan Cain argues in “Quiet: The Power of Introverts in a World That Can’t Stop Talking”,
There’s a less obvious yet surprisingly powerful explanation for introverts’ creative advantage — an explanation that everyone can learn from: introverts prefer to work independently, and solitude can be a catalyst to innovation. As the influential psychologist Hans Eysenck once observed, introversion “concentrates the mind on the task at hand, and prevents the dissipation of energy on social and sexual matters unrelated to work”.
Indeed, I’m personally not a fan of pair programming or design-by-committee. I do my best work by myself with headphones on to cut out distractions. The problem isn’t that introverts are bad software engineers, it’s just that we’ve swung too far in the anti-social direction by letting our introversion run unchecked.
There’s a time for independent work and a time for collaboration. The balance between the two is different for every team, but I’d argue that — especially in a world of remote work — most teams aren’t collaborating enough. We introverts are too good at avoiding the things that cause us stress: meetings, social events, ad-hoc design discussions, difficult discussions about timelines, etc. I know multiple engineers who have excitedly joined a new remote team only to find that their new teammates avoided talking to them, or maybe even forgot they existed. Needless to say, those teams did not scale well.
Every team member is responsible for building a good culture, it’s not something that managers can unilaterally dictate. Your company can organize a holiday party, but they can’t make your coworkers like you. They can’t make you have meaningful 1:1s with your teammates, or productive design reviews. Just as a company with too many middle-managers will develop so much overhead that nothing ever gets done, a company with too many anxious introverts will develop such weak bonds that great teams never get built.
Why it matters
In truth I feel a bit silly writing this post because, from where I stand, it’s all completely obvious. Once you accept that a single programmer can’t change the world by themselves, the problem of making great software becomes a problem of effective team-building. This knowledge is baked into the org charts and promotion ladders of every successful tech company. It’s hardly a groundbreaking new idea.
Unfortunately, I don’t get the sense that people outside the industry know this. The misguided belief that engineering excellence comes from individual mastermind programmers is built into the way colleges teach computer science (individual homework assignments where collaboration is cheating), the way Hollywood portrays programmers (scruffy loner savants), and even the way many engineers get hired (solo coding exercises).
The truth is that Software Engineering, like all office jobs, eventually becomes a game of leadership, conviction, and connections. The so-called ‘soft skills’ are just as important as programming talent. If you like your coworkers, and they like you, you’re on a good path. Wait… maybe the real 10x work was the friends we made along the way.
