Naming Things Is Hard

I’ll probably never publish this, but I’ll probably read it from time to time.

There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.

That joke has mass because the second one is true. Not “hard” the way a math problem is hard — hard the way a promise is hard. Hard because you’re committing a string to a future you can’t see, and every downstream system, every human who encounters it, every context you failed to imagine, will hold you to it.

I’ve been naming things professionally for twenty-four years. Products. Product families. Variables. Functions. Directories. URLs. Domain names. Database tables. API endpoints. Config keys. Services. Repositories. NPM packages. Chrome extensions. CLI tools. Entire companies.

Every single one of them was fraught.

Not because I’m precious about it. Because I’ve been around long enough to know what happens when you get it wrong.

You name a variable temp at 2am and six months later someone’s grepping for it during an outage and getting nine hundred hits across forty files. You name a directory utils and it becomes load-bearing architecture that three microservices depend on by path. You name a URL and it’s a contract with the internet — a string that gets bookmarked, linked, indexed, cached, and screenshotted in ways you will never control. You name an NPM package and it sits in a global registry next to every other decision anyone ever made, forever.

I worked at a company called The Motley Fool for seventeen years. Years of muscle memory had me reaching for foo as a throwaway variable while thinking through a problem. Try grepping for foo in a codebase owned by a company with Fool in the name. I switched to derp. It was greppable, unambiguous, and unmistakably mine. Pretty sure others adopted it once they saw it in the codebase. I have no idea if any of them understood why.

You name a product and now you’re making a promise to strangers. Does it tell them what this thing does? Will it survive their first encounter without explanation? Will it age? Will it lie? Can you live with it when the thing it names fails?

I named a deployment tool dipship. That name works because it’s honest — it’s funny, it’s irreverent, and it tells you exactly what it does. It earned the joke by being useful. I named a product family The Loom — a single word that fuses the metaphor (weaving) with the mechanic (weaving apps). I named a heritage site iron.fyi — two syllables, a material that endures, a TLD that declares posture. Information. Not opinion. Not sales. Here’s what this thing is.

Every one of those names cost me something. Hours of staring at domain registrars. Lists scrawled on legal pads. Names that sounded right at midnight and wrong at seven. Names I bought and never used. Names I shipped knowing I’d be explaining them for years. Names where the .com was taken so I had to find a TLD that wasn’t just a fallback but actually meant something.

And through all of it, the same questions, every time:

Will this make sense to someone who wasn’t in the room?

Will this survive a context I can’t see yet?

Does this name lie about what it contains?

Can I live with this when it breaks?

These aren’t style questions. They’re engineering questions. A name is the first piece of architecture. It’s load-bearing. Everything that comes after hangs from it.

Winston Churchill — a man who understood that language is infrastructure — once wrote a memo about naming military operations. The operations in which many people would die, he said, “ought not to be described by code-words which imply a boastful and overconfident sentiment.” Nor should they have “a frivolous character.” He didn’t want some mother to learn that her son was killed in an operation called “Bunnyhug.”

Churchill understood that when the stakes are life and death, the name is a contract with the dead. Not with the press. Not with the public. With the people who won’t come home.

For decades, the American military mostly understood this too. The naming tradition tracked a rough arc that tells you a lot about institutional character.

The first era was descriptive. Overlord. Desert Shield. Desert Storm. These names described the operation itself — what it was, where it was, what it would feel like. They were geographic, operational, almost clinical. They didn’t need to sell anything. Institutional confidence doesn’t preen.

The second era was justificatory. Just Cause. Enduring Freedom. Iraqi Freedom. These names embedded the moral argument in the title. If you have to put your justification in the name, you’re not confident the operation will speak for itself. “Just Cause” was mocked as “Just Because” almost immediately. “Enduring Freedom” endured for twenty years and then the Taliban retook the country in eleven days. The name outlived the thing it promised.

The third era — the one we’re in now — is affective. Midnight Hammer. Southern Spear. Epic Fury. These names don’t describe the operation. They don’t justify it. They describe how it feels to deliver violence. They’re not about what we’re doing or why. They’re about the emotional experience of hitting someone.

That’s a real shift. From geography to justification to pure vibe.

In September 2025, the Department of Defense was renamed the Department of War.

The 1947 rename — from War to Defense — wasn’t bureaucratic. It was philosophical. A generation that had just watched the world burn twice decided that posture matters. The most powerful military in human history chose to define itself by what it would prevent, not what it would inflict. That was a naming decision. A deliberate, load-bearing, architectural naming decision.

Reversing it wasn’t “restoring heritage.” It was abandoning the lesson.

And then, five months later, the Department of War launched Operation Epic Fury.

The president later told a rally crowd how the name was chosen. He said they gave him a list of twenty names. He said he was falling asleep. He picked one.

Falling asleep.

I have spent more time naming a config directory than the president of the United States spent naming a war in which people are dying. I have agonized longer over a two-character variable prefix than this administration agonized over the string that would follow the words “your son was killed in…”

Here’s what I know after twenty-four years of naming things:

The discipline of naming is the discipline of giving a shit. It’s the first signal — before the code, before the product, before the operation — that someone in the room is thinking past the moment. That someone is looking over the horizon, around the corners, into the dark parts of the room. That someone understands they’re making a commitment to a future they can’t control.

When a name is chosen carelessly, it tells you everything. Not about the name. About the namer.

A product named carelessly will confuse its users and embarrass its maker. A variable named carelessly will cost someone a night of debugging. A military operation named carelessly — named like a Mountain Dew flavor, named like a video game achievement, named while falling asleep — tells you that the people in charge aren’t building anything. They’re performing.

Naming things is hard because it requires you to compress the truth of a thing into a string that has to survive contact with reality. It requires honesty about what the thing actually is, humility about what you don’t know, and respect for every person who will encounter that string without you there to explain it.

Every string is a promise. Some of us know that. Some of us have the scars to prove it.

And some of us fall asleep.