Naming things is half the design

A name that explains itself does more work than a feature that doesn't.

The underrated skill in product, code, writing, and operations is naming. A good name is a small interface that the rest of the system depends on. A bad name is a tax forever.

The cost of a bad name is paid every time someone has to remember what the name means, what it doesn't mean, and what they're supposed to think of when they see it.

The benefit of a good name is that nobody has to think about it. The name does the thinking. The reader sees the name and instantly knows what it refers to. No translation. No glossary. Just understanding.

Naming is hard because the right name is usually the second or third one you tried. The first one was descriptive. The second was clever. The third was both clean and accurate. Most teams ship the first.

Three rules I follow:

Spend disproportionate time on names. The name is more permanent than most of the code around it. Get it right.

If you can't explain the name in one sentence to a smart stranger, the name is wrong. Either the name is wrong or the concept underneath the name is unclear. Both should be fixed.

The best names are short, specific, and hard to misread. "Customer" is better than "Client_record_v2." "Login" is better than "User_authentication_endpoint."

Naming is design. Treat it as such.

The named thing is what the rest of the system has to live with.

Pick well.