I'm sick of being a 10x programmer

I'm sick of being a 10x programmer.

Back in the long, long ago, legend has it that some researchers made an earnest attempt to measure programmer productivity and discovered that among a sample of professional developers given the same task, the fastest ones completed it ten times faster than the slowest.

The observation that some developers are ten times faster than others was corrupted into a crude belief that there existed an entity, known as the “10x programmer”, who was ten times more productive than the normal developer. Lots of people tried to find such people, or become such people, and failed. The idea of the “10x programmer” fell out of fashion, was mocked, and faded. Prevailing wisdom is these days that the original study was flawed because programming is a holistic practice that is unmeasurable. Goodhart's Law is often quoted.

The mischaracterisation of the study's findings you probably spotted above, the one that took “ten times faster than the slowest” and turned it into “ten times faster than normal”, might seem minor, but it's key. Because when you think about the measure – the time that it takes to complete a task – and think about what is theoretically possible, it becomes clear that there's a pretty fundamental limit on how fast the fastest time is – you can't take less time than no time, after all. Whereas there is no limit on how long a task can take. And in practical terms, a programming task will involve typing out a bunch of stuff. Humans only type so fast, especially when they're having to insert a bunch of arcane syntax like braces and parentheses, dollar signs and colons, which involve extensive use of the shift key. Even if a programmer could see in their heads exactly what they needed to type and got everything right first time, there really is only so fast they could get the task done. Whereas a programmer who got confused, got stuck, went down a rabbit hole, etc... well, it's easy to see how a mountain could be made out of a molehill, and a simple task could be turned into a multi-day epic of unproductivity.

I'm trying to convince you that a 10x disparity in developer productivity is highly plausible, not because of rare, mythical creatures who are improbably fast, but because of disappointingly common creatures who are laughably slow. I want you to believe that this is real by appealing to your intuition about human incompetence. You might not be convinced. In which case I must turn to my other argument, which I make from direct, first-hand experience:

I am a 10x programmer.

I am also pretty unspectacular.

I've been coding for a decade and a half, doing pretty bog-standard web development. You want a CRUDdy web app written in Rails? I can do that. I don't solve hard problems, and I don't work at the cutting edge of anything. I do the boring stuff. No one is paying me to be a genius. I never studied computer science. I'm not hugely excited by my work; I do it for the money, and outside work I don't spend much time coding. Prodigy I ain't. I am proud to be competent, but I don't flatter myself that I am any kind of genius.

I work at a large public sector organisation. My current team includes two other full-time, hands-on developers. We are all three of us contractors, all experienced, all well paid. (The organisation is constrained by hiring rules that prevent them paying market rates for permanent developers. They therefore have a constant shortage of developers, so they fill the gaps with short-term contractors to get around their hiring rules, then end up keeping those contractors around for long-term contracts despite paying short-term day rates – with tax-payer money, of course.)

We work in 2-week sprints, and we measure our output in story points. In the last sprint, the three of us completed 44 story points. Of those, I did 36. The previous sprint we completed 47 story points. Of those, I did 47. That is not a typo. Admittedly, one of my colleagues was on holiday for half that sprint, but between them they achieved 0 story points in 15 developer-days.

So far this sprint I have completed over 30 story points, and no one else has completed any. Although to be fair both of them have completed tasks that would total around 3-5 story points apiece, it's just that they both picked up tasks that hadn't been properly pointed and neither of them went through the process we have for getting story points assigned to tasks because they haven't got the hang of the team's processes. And this is another notable facet of them: aside from (not) producing lines of code, they also do not do many of the other things that are part and parcel of being in a software development team.

I am the only developer who responds to incoming error alerts from our production deployment, investigating, ticketing up fixes and communicating findings to non-technical colleagues.

I am the only developer who reviews, tests and deploys automated dependency updates.

I am the developer who non-developers in my team ask technical questions of.

I am constantly being blocked by the requirement that all the code we write needs to be reviewed by another developer. My colleagues are extremely loath to review code.

On Friday, one of my colleagues spent all day rotating 2 secrets in non-production environments. It was a task that should have taken ten minutes. And he still got it wrong. The other colleague didn't appear to do anything at all.

There are some things they do do. They turn up to most of the video calls, daily standups, weekly product refinements, fortnightly sprint retrospectives, and so on. They are polite, enthusiastic and always happy to share opinions about team processes, technology choices, architecture and so on. From their participation in meetings you'd never suspect they weren't committed, productive, effective members of the team. Not unless you paid a lot of attention to the specifics of their technical opinions and fact-checked them rigorously enough to realise that a good two thirds of them were, in fact, utter gibberish.

And the code, when they do write it, is... not good. Basic logic errors, code smells, antipatterns, obvious bugs, seemingly wilful misunderstandings of requirements... I hold my nose when reviewing, and don't complain about anything that's remotely subjective or doesn't affect whether the code is functionally correct or not, but even so, it always takes at least two rounds of feedback to get to anything remotely production-ready.

This is the third team in a row where I have been ten times as productive as at least one member of my team. Normally, though, there's at least one other developer who's at least reasonably competent. And normally the slow developers are permanent employees, and therefore it's excusable that they'd be hopeless because they're being paid peanuts.

I am a 10x programmer, and that is a damning indictment of the hiring practices of the organisation I work for.

We all work remotely. My colleagues could achieve similar levels of output by skiving off for seven hours a day and only actually working for one. But I don't think that's happening. I think they are, to the extent they are capable of, doing the best they can. I think they have trouble sustaining focus, and I think when they are focusing they are, simply put, not at all clever. They constantly misunderstand. They get confused. They get stuck. (They are, incidentally, extremely enthusiastic about AI: they often ask it for help with things and apparently find its answers helpful. Their experience is so different to my own that I suspect that the sorts of technical questions they ask it are at a very different level to the few I have tried asking it.)

So how the hell did they get hired? Well, as I say, there are two sorts of hires at my organisation. The first is permanent employees, who are hired through an intensive, structured process hampered only by the fact that advertised salaries are 30 – 50% lower than market rate, meaning that apart from a few idealistic souls who apply because they can't face the idea of working in the private sector, their pool of candidates is pretty much exclusively people who couldn't get hired anywhere else. The second is contractors, for whom the interview process is primarily, as my first line manager put it, 'vibes-based.' Contractors are assumed to be good at their jobs: how else would one get to be a contractor? How else would one gain the audacity to ask for hundreds of pounds (yes, this is in the UK) more per day than a permanent hire? And in an organisation where the talent pool is so shallow, where teams so routinely fail to deliver much of anything, it can be pretty hard to notice when a contractor can't actually code.

In my current situation, one of my colleagues has been noticed to be incompetent by those with the power to hire and fire. Being a contractor, in theory his employment could be terminated without notice, but in reality a decision to terminate can't be made without months of escalations and hoop jumping. I am told by my line manager that we are near the final warning stage with this colleague – as though being warned could prompt him to magically discover a hitherto latent talent for his profession – but for the time being he keeps charging his day rate and producing almost nothing in exchange. And for reasons that escape me, even though by every conceivable metric my other colleague is similarly non-productive, that other colleague remains in good standing with the organisation.

I hate it. I hate constantly not talking about the elephant in the room, which is that, effectively, I am responsible for every feature we release, every bug we fix, every change we make to improve speed and reliability. I hate feeling like a weirdo and an outsider when what sets me apart is simply that I'm actually doing the thing we're all being paid to do. I hate feeling the responsibility that if anything needs doing urgently, or needs doing correctly, it effectively has to be me who does the work.

I am a 10x programmer, and I would really like to stop now, please.