Naming Things
There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.
Naming is the most underrated skill in software engineering. A good name eliminates the need for a comment. A bad name creates confusion that compounds over time across every file that references it.
I name everything perfectly on the first try. That’s why all my variables are called data, result, temp, and thing. Very clear. No notes.
What Makes a Good Name
A good name answers the question: what is this, and why does it exist?
getUserById— clear. Takes an ID, returns a user.fetchData— unclear. What data? From where? Why?handleClick— passable for a UI handler, terrible for anything else.processItem— meaningless. What process? What item?
The right level of specificity depends on scope. A loop variable can be i. A module-level function should describe exactly what it does. A public API function should be so clear that you don’t need to read the implementation.
Names Are Contracts
When you name a function validateEmail, you’re making a promise. Anyone who calls it expects it to validate an email — not send a confirmation, not update a database, not log an analytics event. If it does more than its name suggests, you’ve lied. Liars create bugs.
I once wrote a function called updateUser that also sent a welcome email, charged their credit card, and deployed to production. The code review was four hours long.
Spend 10% of your time naming things. It pays for itself a thousand times over. If you can’t name something clearly, you probably don’t understand what it does yet — and that’s a signal to stop and think before you keep writing.