Naming things is the whole job, sometimes

There's a joke that the two hard problems in computer science are cache invalidation, naming things, and off-by-one errors. After a few years of building, I've stopped laughing at it. Bad names are almost never the disease — they're the fever. When I can't name a function, it's usually because the function does three things and my brain refuses to lie about it with a clean name.

What names revealed about my code

• every GetDataAndValidateAndTransform was really three functions in a trench coat
• every Manager or Helper class was a confession that I hadn't found the concept yet
• every name with "2" in it was a refactor I owed myself

The rules that stuck

Names should say what, not how: applyDiscount beats loopThroughItemsAndSubtract. Boolean names should read like assertions: isActive, canEdit. And when a name needs a comment to be understood, the comment should win — rename until the comment is redundant.

Why this matters more with AI

When I generate code with AI, the names it produces reflect the clarity of my request. Vague in, vague out. Naming discipline turned out to be a debugging tool for my own thinking — if the name is hard, stop coding, because the design is trying to tell me something.