Naming things is the whole job, sometimes
Most codebases don't have a naming problem — they have a thinking problem that shows up in their identifiers.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer
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.
Keep reading
- Software engineering
Your README is your first interview
Before anyone judges your code, they judge your README. What a good one actually contains, from someone who reads a lot of them.
- Software engineering
The bug that taught me to read error messages properly
A three-line error sat in my logs for a week. It told me exactly what was wrong. I just never read past the first line.
- Software engineering
CSS taught me more about engineering than I expected
Specificity, inheritance, and the cascade are systems thinking in disguise. Understanding CSS made my other code better.