In half the fantasy novels on my shelf, knowing a thing's true name gives you power over it. Speak the name correctly, and the dragon must answer; get it wrong, and the working slips through your fingers.
Programmers already knew that.
The variable is the spell
A poorly named variable is a spirit you've bound without understanding. It does what you told it to, technically, but the compact between you and the thing you've summoned is fuzzy — and fuzzy compacts are where bugs live. data, temp, x2 — these are the equivalent of pointing at a shape in the fog and hoping it stays put.
A well-named one is closer to a proper invocation:
const overdueInvoices = invoices.filter(inv => inv.dueDate < today);
You can read that line without opening a second file to remember what it means. The name is doing the work of documentation, contract, and constraint all at once — which is exactly what a true name is supposed to do.
Naming as a design act
The old texts agree on one more thing: naming isn't neutral. To name a spirit is to define the boundary of what it is and is not. Naming a function forces the same discipline — if you can't name it without an "and" in the middle (validateAndSaveAndNotify), it's not one spirit, it's three wearing a coat.
Split it. Name each one honestly. The rest tends to follow.