Why Naming Things Is So Hard

There's an old joke in software: the two hardest problems in computing are cache invalidation, naming things, and off-by-one errors.

People laugh because it's true. But I don't think they always understand why it's true.

Naming a thing isn't decoration. It's not the last step, the cosmetic layer you apply after the real work is done. It's the moment you discover whether you actually understand the thing you've built.

When a name comes easily, it's usually because the concept is clear. The function does one thing. The variable holds one kind of value. The idea is crisp enough to compress into a word or two without losing anything.

When a name is hard — when you cycle through five candidates and none of them fit — that's information. It usually means the thing itself is confused. You've built something that's trying to be two things at once, or you've blurred the boundary between what it is and what it does, or you haven't quite decided yet what problem it's actually solving.

The temptation is to pick something vague and move on. Manager. Handler. Helper. Words that mean almost nothing — and therefore can mean almost anything.

But vagueness has a cost. Every future reader (including you, six months later) has to reconstruct the intent from context. The name that was ambiguous enough to be convenient becomes a small, chronic tax on comprehension.

The same thing happens outside code. When you can't explain what a meeting is for. When a project title is a word salad. When someone's job title tells you nothing about their job. The name wasn't hard because language is limited — it was hard because the thing behind the name wasn't fully formed.

A good name isn't clever. It's just precise. And precision is another word for understanding.

---

Photo by Armand Khoury / Unsplash