There's a mythology around the 10x developer. You know the image - some genius in a dark room, mechanical keyboard, four monitors, grinding out code at an inhuman pace while the rest of us mere mortals chip away at our ticket queue.

I don't buy it.

Every developer I've seen move that fast isn't faster at writing code. They're faster at figuring out what needs to exist before they write a single line. The 10x developer isn't a better typist. They're a better translator - between the messy, human, irrational world of the business and the clean, logical world of the system.

And here's the part nobody says out loud: the translation is the job. The code is just what it looks like when you're done.

The Insight Came First

People hold up Linus Torvalds like he's proof that raw technical ability is the ceiling. And sure, the man is one of the best systems programmers alive. That's not the argument.

The argument is that git didn't come from his ability to write C. It came from understanding distributed version control across a chaotic, open-source project more precisely than anyone else had at the time. He didn't build a faster version of the existing tools. He understood what they got wrong about the domain.

That's the pattern. The developers who build things that matter aren't the ones who know the most syntax. They're the ones who've built the most accurate model of what they're building for, and then found a way to get it out of their head and into a shape other people can use.

Requirements Gathering Is a Symptom

Every dev blog eventually writes the soft skills article. Communication. Empathy. Stakeholder alignment. All true. All real. All completely missing the point.

You can't gather good requirements for something you don't understand. Good requirements come from domain knowledge, and that is not a soft skill - it is a technical one.

Here's what it actually looks like. Say you genuinely know how a project controls department operates. Not the software layer on top of it - the real thing. The business processes, the SOPs, the Excel workarounds they built because the system never did what they needed. When someone from that team asks for a new report, you already know half the answer before they finish the sentence. You know the inputs. You know the outputs. You know what pain they're currently eating that prompted the ask. The only work left is helping them say what they actually need instead of what they thought to ask for.

That is a completely different job than reading a ticket and writing code to spec.

"But isn't that what the PMs and analysts are for?" Sure, and your DI framework resolves your dependencies for you. That doesn't mean you shouldn't understand what scope your services are running at, or what blows up when a scoped service leaks into a singleton. The abstraction exists to help you move fast. It is not a substitute for understanding what's underneath it. Same deal.

The Real Skill Is Drawing the Map

Here's where most people stop short. They learn the domain, build the mental model, and keep it in their head. That's where it dies - when the project ends, when they change jobs, when the one person who knew how everything fit together walks out the door.

The skill isn't understanding the business. Plenty of people understand the business. The skill is pulling that understanding out of your head and giving it a shape someone else can work with.

Sometimes that's a data model. Sometimes it's an API boundary drawn in exactly the right place. Sometimes it's a twenty-minute conversation where you reflect a stakeholder's own process back to them more precisely than they could've said it themselves. The medium changes. The act is the same.

That's also why the best developers make everyone around them faster. It's not that they write more code. It's that they keep externalizing the model - in schemas, in interfaces, in conversations, in documentation nobody hates reading - so the implicit becomes explicit and the whole team can build on top of it instead of just them.

How You Get Better at This

Same way you get better at anything: on purpose, over time.

Next ticket that lands in your queue - don't start with the implementation. Start with the why. Why did someone need to ask for this? What are they doing today that makes this necessary? What does a good outcome actually look like for them, not just a closed ticket?

Learn to be a beginner in a domain the same way you're willing to be a beginner in a new language or framework. Ask the questions that feel too basic. Read the process documentation. Sit with the people doing the work. The developers who do this aren't the ones hiding their ignorance - they're the ones who got comfortable with it long enough to get past it.

The ceiling on your career isn't how fast you can write code. It's how fast you can understand what should exist, and get it out of your head in a form that compounds.

One of those things you're probably already grinding. The other one is just sitting there.