On naming things well
A name is a contract. It tells the future what to expect, and the past what it meant.
Names are the first design decision and the last thing anyone changes. This is backwards. The name should be the last thing you decide, after you know what the thing actually is.
I have watched teams spend hours naming a feature before they have built it. The name becomes a brief, a promise, a constraint — usually the wrong ones. Then the feature ships, the name is printed on a button, and six months later nobody can remember why it was called that or what it was supposed to do.
The problem is not that naming is easy. It is that naming is the easiest feeling hard decision. You can have a conversation about a name without having built anything. You can have a strong opinion about a name without knowing anything about the underlying system. This is comfortable in a way that design and engineering rarely are.
A name is a contract. It tells users what to expect, colleagues what is meant, and your future self what you were thinking. A bad name is a debt — small at first, compounding with every new person who encounters it and has to learn the gap between what the name implies and what the thing does.
How to name things
I do not have a formula. What I have is a heuristic: a good name makes the wrong use feel wrong. If the name doesn’t constrain the thing, it is not doing its job.
handleClick is not a name. handleFormSubmit is marginally better. validateAndSubmitPaymentForm is honest, if unwieldy. The test is: can you use this name in a sentence that makes a false claim obvious?
The other heuristic: prefer boring names. The clever name is a signature — it tells the world that the person who wrote this was enjoying themselves. The boring name is a service — it tells the world what is there. Boring names age better.
I am still thinking about this. The names I regret most are the ones that seemed precise at the time.