Naming gets filed under style, somewhere near indentation and bracket placement — a matter of taste, worth a little care but not real work. That undersells it badly. A name is the interface between a concept and everyone who will ever touch it, and choosing one forces you to answer a question you can otherwise dodge: what is this thing, exactly? You can write a function that works without being able to say cleanly what it does. You cannot name it well without saying it. The name is where fuzzy thinking has nowhere left to hide.

Which is why the struggle to name something is diagnostic rather than annoying. When a good name won’t come, the usual reason isn’t that your vocabulary is thin — it’s that the thing itself is confused. A function you can’t name concisely is usually a function that does more than one thing, and the name resists you because there’s no single concept there to capture. A variable that only fits a vague name like data or temp or result is often a variable whose role you haven’t actually pinned down. The naming difficulty is the code reporting a design problem, and the honest response is to fix the design, not to reach for a longer, mushier name that papers over it.

This flips the usual order of operations. People treat naming as something you do at the end, a light cleanup pass over code that already works. But if the name is where understanding gets tested, then naming is part of the thinking, not a coda to it. Trying to name a thing before you build it — or the moment you notice you can’t — surfaces the muddle early, while it’s cheap to resolve. The function that splits cleanly into two once you try to name it is far easier to split now than after twenty callers have grown around its confused shape. The name isn’t decorating the design; it’s revealing whether the design is any good.

The payoff shows up every time someone reads the code afterward, which is far more often than anyone writes it. Good names let a reader understand a piece of code without executing it in their head or chasing its definition — the call reads like a sentence, and they can move on. Bad names force the reader to reconstruct meaning the writer failed to capture: open the function, trace the logic, hold the real behavior in their head because the name lied or shrugged. Every vague name is a small tax levied on every future reader, and code is read so many more times than it’s written that these taxes dwarf the few seconds saved by not thinking hard about the name once.

None of this makes naming easy, and it isn’t — it’s genuinely one of the harder parts of the craft precisely because it demands the understanding, not just the typing. But that’s the reframe worth keeping: the difficulty is the point. A name that comes easily usually means the concept is clear; a name that fights you usually means it isn’t, and the fight is doing you a favor by telling you so before the confusion sets into the structure. Treat the search for the right name not as wordsmithing but as the last check on whether you actually understand what you just built. Most of the time, when you finally find the name, you’ll find you understand the thing better than you did a minute ago — and occasionally you’ll find you didn’t understand it at all.