Naming Things Is Still the Hardest Problem

The old joke says there are only two hard problems in computer science: cache invalidation and naming things. Cache invalidation gets all the conference talks. Naming things quietly costs teams more hours, spread thin across years, in the form of code nobody can read without asking the person who wrote it what it actually does.

A bad name is a small lie, repeated forever

A function called processData that filters, transforms, and occasionally sends an email is not saving anyone time. It is deferring the cost of understanding it to every single person who reads it after you, indefinitely, until someone finally renames it, usually while also trying to fix an unrelated bug under deadline pressure.

We treat naming as a design decision, not an afterthought typed in while thinking about something else. If a name is hard to choose, that is often a signal the thing itself is doing too much, and the naming difficulty is a free, early warning that would otherwise have shown up later as a difficult pull request review or a confusing bug report.

What we actually do about it

Code review at Common Sense treats a genuinely confusing name as seriously as a logic bug, because in practice it becomes one eventually, once enough people have built the wrong mental model from it. We would rather spend two extra minutes in review agreeing on a clearer name than spend two hours six months from now figuring out what a vaguely named function was actually for.

If you cannot name it clearly, you probably do not understand it as well as you think you do yet.

It is a small discipline. It compounds like every other small discipline does, quietly, into a codebase where new engineers can actually find their way around without a tour guide.