It sounds absurd that naming variables and functions is considered one of the hard parts of programming. Yet experienced developers agree it genuinely is, and they treat it seriously. A name is not decoration; it is the primary way future readers — including your future self — understand what code does without reading every line.
The difficulty is real because a good name requires real understanding.
A name is understanding, compressed
To name something well, you must first understand exactly what it is and does — its single, precise responsibility. Vague or misleading names are often a sign the thing itself is vague or does too much. In this way, the struggle to name something is diagnostic: if you cannot name it cleanly, the design may be muddled.
The best names capture intent, not mechanism — what something is for, rather than how it happens to work today.
The cost of bad names
Poor names impose a tax on every future reader. A misleading name is worse than a vague one, because it actively sends people in the wrong direction. Code is read far more often than it is written, so a name that saves a few seconds now but costs every future reader minutes of confusion is a bad trade repeated endlessly.
Abbreviations that made sense to the author, single-letter names outside tiny scopes, and names that no longer match what the code does are all quiet sources of friction.
Practical habits
Favour names that reveal intent and can be read aloud; keep them honest by renaming when behaviour changes; and let the difficulty of naming prompt you to reconsider whether a function or variable is doing too much. Consistency across a codebase matters too — the same concept should wear the same name everywhere.
Naming is hard because it forces clarity of thought. That is exactly why the effort pays off: a well-named codebase is one that explains itself.