June 15, 2026
Who Gets to Be a Developer
This post is part of my Medium blog.
The conversation about who belongs in software development has always had a weirdly exclusionary vibe to it. Not always loud. Not always obvious. But there, underneath the arguments about craftsmanship and quality, like something you can smell but can't quite name.
I remember reading a book about Extreme Programming in my apartment in New York. This would have been the early 2000s. XP was the hot thing — pair programming, test-first, the whole methodology. The book had a certain edge to it. A kind of martial certainty about how software should be built and who should build it. And then I got to the bibliography and saw Erwin Rommel listed as a reference.
Rommel. The Nazi field marshal. In a bibliography of a book about software development methodology.
Someone thought that was appropriate. Someone thought that signaled the right kind of toughness, the right kind of discipline. And no editor, no reviewer, no colleague pulled them aside and said hey, maybe not.
That's the thing about developer culture. The exclusion was never just subtext. People would come right out and talk about testosterone. About which languages were "manly" and which weren't. About whether women could really understand the hard problems. Not in private. On stage. At conferences. In print. And the rest of the community treated it like a personality quirk, or a difference of opinion, or just how things were.
So when a mild post about clean code and coding agents hits the front page of Hacker News and the comments turn into a fight, I don't read it as a debate about code quality. I read it as the latest round of a very old argument about who counts.
What people say they're debating is whether AI-generated code is clean. What they're often actually debating is who gets to call themselves a developer, who gets to speak with legitimacy, and who is allowed to build things without first being blessed by the right subculture. Sure, some of the criticism is valid. A lot of generated code is clumsy. But that is not the whole emotional charge behind these conversations.
The deeper complaint, the one people don't always say out loud, is that software creation is becoming available to people who were never going to come up through the old credentialing path. People who don't know the liturgy. People who aren't comfortable with books that list Rommel as a role model. People who wonder why they need to pay attention to some old guy who talks about manly programming languages and who everyone calls Uncle. People who may build awkwardly at first, but who are building anyway.
That's what has some people rattled.
Because once that starts happening at scale, "real developer" stops being a description of skill and starts looking a lot more like a border checkpoint.
Yes, there is a real engineering question underneath all this. Readable code matters. Simplicity matters. Tests matter. If you are using coding agents to spray undocumented nonsense across a codebase, you are creating maintenance debt for whoever has to clean up after your experiment. That part is true.
But "clean" has never been just a neutral description of code. The standards we use to judge code quality came from specific communities with very ordinary human biases, status games, and blind spots. Some people were welcomed into that world. Some people got the message very clearly that the culture was not built with them in mind.
That history doesn't disappear just because someone says "I only care about the code."
Hacker News is part of this too. It is not some neutral public square hovering above the industry. It is a platform owned by Y Combinator, shaped by Y Combinator, and reflective of the kinds of people and companies that ecosystem has historically elevated. If you think the conversation there is just "what developers naturally care about," you are already accepting a frame that hides the gatekeeping.
And to be clear, not every standard is exclusion. If you work on a shared system, you owe other people code they can understand and maintain. But there is a difference between defending maintainability and defending a priesthood. The industry is bad at admitting that difference because it likes to confuse aesthetics, status, and ethics — turns preferences into principles, then principles into admission criteria.
You can see the pattern.
A new group of people starts building with tools that lower the barrier to entry. The incumbents say they're only worried about quality. Some of them really are. But mixed in is the older, uglier impulse: protect the boundary, defend the identity, keep the definition of "developer" narrow enough that the right people still get to feel distinct.
That's not a technical instinct. That's social closure with a GitHub account.
And here's the new part that's making it acute. A lot of people writing good software now don't care to learn vi. They don't know what "grok" means and they don't see why they should. I've started talking to people who have concluded, for better or worse, that git is an unnecessary technical barrier — that version control shouldn't require memorizing a command-line interface designed in 2005.
You can argue with any of those positions individually. You can make the case for vi, for understanding the jargon, for git as a foundational skill. Some of those arguments are good. But that's not really what's being defended here.
What these defensive programmer communities are holding on to is an identity, not a profession. The specific tools, the shared vocabulary, the initiation rituals — they're not how you do the work. They're how you prove you belong to the group that does the work. And when someone shows up who can build working software without having passed through those gates, it doesn't just challenge the tooling. It challenges the identity.
And that's the line that runs all the way back to the beginning. It's a defensiveness that justifies exclusion. It's been part of developer culture since before that term existed. That "you are not one of us" feeling is especially strong whenever you hear someone talk about "clean code."
The tools are changing who gets to build. That's not going to stop. The work still needs judgment, taste, debugging, responsibility — if anything, more of it, from more people. When the person who understands the problem domain can also build the prototype, the prototype is better. When the person who lives with the system can also read the code, the maintenance is better. Inclusion isn't charity. It's how you get software that actually works.
If your answer to all this is "only after they learn our sacred vocabulary," then you're not defending engineering. You're defending hierarchy. And you're doing it with the same language people have always used to keep the door closed — politely, in the name of quality.
In Redundant, the first book in The Condition Set trilogy, this is Brett Cawley — the coworker who seems reasonable, who cares about "quality," who talks about how things used to be. He's not wrong about the code. He's wrong about the world he thinks the code belongs in. Rob Coleman runs the FinOps review that names the waste nobody wants to hear about, and Brett is the one who turns that waste into a weapon — not because he's a cartoon villain, but because he genuinely believes the wrong people are in the room. The chauvinism isn't a character flaw. It's the whole point.