There's this old and slightly stale debate about 10x programmers. Either they exist, or it's a startup myth, or it's just managers daydreaming about "let's hire one wizard instead of a team." In presentations, posts, and conversations this topic came up regularly, usually somewhere next to "we need strong people," "we have a small team," and "the deadline was yesterday" — and against the backdrop of AI agents it has bloomed wildly all over again.
What always bothered me about this topic is that people try to cram absolutely everything into "10x": coding speed, the ability to fix bugs, knowledge of the project, the ability not to hurt the project, experience communicating with management, architectural taste and seasoned experience, willingness to sit up at night, and a luck buff. And then out of all that they build a beautiful legend about a person who works ten times faster than everyone else.
A PM's dreams are still just dreams, and in real life everything is duller and more interesting at the same time. I've seen people who really did get tasks done much faster than others. I've seen it in open-source, in game projects, on old code, in small libraries. But almost always the reason wasn't that the person was born with an x10 coefficient and a buff to the speed of typing letters, but that behind their speed stood some accumulated capital — like knowledge of the project, of a tool, narrow expertise, or years of digging through similar tasks.
The person who fused with the project
The most obvious type of "10x" programmer is the person who simply knows the project better than anyone. Yes, those exist too. Usually they're loyal and gray-haired. In old codebases or projects it looks almost like magic: you drop into Slack to ask about a bug, and a couple of minutes later an answer arrives saying which file to look in and what to fix. Rare, but it happens. Or you say "the window behavior broke on such-and-such transition," and the person remembers that three years ago there was a hack there for a different screen, then it was bypassed with a flag, then someone added an exception for the tutorial. And yes, most likely they're right again.
In old game projects this is especially noticeable, and games "with a legacy" quickly show that "knowing C++" and "knowing the project" are two very different things. You can be an excellent programmer but spend the first month or two simply walking through a minefield of old formats, strange dependencies, historical decisions, and behavior that players remember better than the documentation.
And here speed appears not from some abstract skill, but simply from memory. You already know where the UI lives, where the simulation is, where the saves are, where it's "better not to touch if you don't want to break half a level." And such people often also remember that this check looks redundant, but without it a scenario breaks. They know that pathfinding behaves strangely not because it was written badly, but because ten years ago you had to stretch the frame, and players have already gotten used to it.
This isn't about 10x — the person simply paid with their time over several years for the ability to fix things faster now. The problem is that you can't just hire such a person off the street, and growing one inside the project is problematic too — not everyone is willing, wants to, or can. And if there's only one of them, the project simultaneously gets a superpower and a huge bus factor, where all the magic rests on one person, their memory, and their willingness to keep going.
Just a fast programmer
There's a second type of efficiency — not writing more code, but writing less. You might say that sounds trite, but in gamedev, especially in gamedev, a lot of time burns up trying to build the "right" system before it's even clear whether it's needed at all. It started with a small feature, and a week later we already have a plugin API, our own serialization, an abstract factory of factories, and a TODO to "refactor later."
It's a disease, I don't know what it's called, and the older the project, the more such hotspots it has. There are especially many of them among tools and UI. It seems like, right now, we'll write it beautifully, universally, for the future. And then it turns out that the future in that form never arrived, but now you have to maintain the universality.
A fast developer simply does less. Somewhere they hardcode, somewhere they put in a hack, somewhere they move it to a config, somewhere they do nothing at all. This kind of professional laziness is already a skill — one that's poorly tested in an interview but very visible after a month or two working on the project.
DoItProperlyMan
If you commit to open-source a lot, over time you come to understand that the code in a project is 20% of the contribution to the project.
You need the project to build, the README not to lie, a new person to be able to get through at least the first ten steps without sorcery. You need a pull request to be reviewable, not a guessing game about what the author meant. You need issues not to turn into a swamp of "it doesn't work for me" without a compiler version, OS, and logs.
And here is where another type of "10x" person appears. They might not write the most lines of code, but they know how to untangle chaos. They can explain where to put a change. They can say "this doesn't go here." They can chop a big task into small ones. They can make it so the next person doesn't spend an evening on the build.
Such a person often doesn't make it into the 10x mythology, because they don't look at all like a hero who wrote a new system overnight. But they smooth the road that everyone else then runs along, and without them those others would "heroically" stumble every ten meters.
Narrow expertise
Sometimes narrow specialization really does give 10x — for example, when a person has rare knowledge; often this overlaps with the first point. Old codebases, custom data formats, rendering specifics, UI-library bugs, build-system quirks, platform bugs, and so on and so forth. All of these are areas where an experienced person can do in a day what another would spend a week or more on, just to figure out which way to look at it.
If you already know how to read old formats, understand how the data is laid out, and aren't scared of code from the early 2000s, then you're already starting not from zero. You already know that a game can be logical within its own strangeness and that a bug is sometimes a historical feature. And also that "improving" doesn't always mean making it better, and you simply spend less time on unknown unknowns. And not because you know everything, but because you understand faster where to look.
Expertise is knowledge multiplied by memory multiplied by exposure and an understanding of the domain. This includes C++, and architecture, and knowledge of a specific project, and an understanding of game systems. And often a person pulls out a bug faster with expertise than with knowledge. Two programmers with the same experience but different expertise can arrive at different results simply because they worked on different projects.
The focus myth
There's a popular idea that strong programmers just focus better on what matters. The truth here, as usual, is half. Yes, the ability to pick an important task is valuable too, but someone also has to do the unimportant tasks. Fixing the build, for example, or updating dependencies. Triaging small bugs. Writing examples. Answering questions. Cleaning up junk. Bringing names to a single form. In short, doing the boring work without which the project also won't look finished.
The problem is that such labor sells poorly as "10x," and it also doesn't look heroic, but for the player it's generally irrelevant how heroically and focusedly you closed the last two tickets — it's precisely such little things that often separate a living project from "well, neat, but painful to use."
10x probably does exist after all, just not the way we want
I don't think a 10x programmer is a person who walks into any project and immediately starts delivering ten times more value. That only happens in fairy tales, open job postings, and motivational presentations. But I quite believe in people who become 10x in some context. In a specific codebase or domain, in a specific team or particular type of task. In a project they've crawled all over with their hands, their eyes, and their backside.
Unfortunately, behind this stands time: years of experience, bad decisions, rewritten systems, abandoned branches, late-night bugs, strange users, broken builds, and the understanding that sometimes the best code is the code you didn't write. So if you want to look for "10x," I'd look not for wizards, but for people who can do three things: quickly understand context, correctly choose the scale of a solution, and leave the project in a state you won't be ashamed to come back to.
This is less beautiful than the myth of the superprogrammer. But it's much closer to how big projects — and really any projects that have survived a year of development — actually live.
← All articles