We have all been there.
You are in the zone. The logic is flowing, the music is loud, and you just need a temporary variable to hold a user object inside a map function.
You could type updatedUserObject.
But that’s 17 characters.
You know what’s faster? u.
u is one character. It’s efficient. It’s fast. You know exactly what u is right now. So you type it, the code compiles, and you feel productive.
You have just set a trap for your future self.
This is the Junior Trap known as the "Keystroke Saver."
It is based on a lie: the belief that typing speed is the bottleneck in software engineering.
It isn't. The bottleneck is reading comprehension.
The Dictionary of Intent
When we use generic names like data, item, or single letters like x, we are hiding information. We are stripping the context away from the logic.
To understand a function full of xs and ds, the reader (which will likely be you in six months) has to hold the entire logic of the program in their head just to map out what is happening. You are burning your teammates' "Cognitive RAM" on a puzzle you created just to save 0.5 seconds of typing.
A variable name is not just a label; it is a definition of intent.
The Junior Trap: The "Keystroke Saver"
"I’ll just name this variable u instead of updatedUserObject because it’s faster to type. I know what it means right now, so it’s fine."
The Pro Move: "Autocomplete Reliance"
Professional Juniors know that code is written to be read, not to be typed.
We live in the golden age of IDEs. VS Code, WebStorm, and IntelliJ are smarter than us. They have Autocomplete.
The Strategy: Type the long, descriptive, intent-revealing name once. Then, hit Tab forever after.
We happily trade three seconds of typing now for three hours of debugging later. When you use descriptive names, you don't need to read the previous 20 lines to understand what a variable holds. The variable tells you.
The Code: The "Data Dump" vs. The Story
Let's look at a classic example of "Mystery Code."
// Before (The Mystery Box)
const data = getInfo();
if (data) {
const val = data.v;
updateUI(val);
}
This code works. The compiler loves it. But a human being looking at line 5 has to scroll up, find the getInfo function, read that function, and figure out what structure it returns just to know if val is a number, a string, or an object.
// After (Intent Identified)
const weatherReport = fetchWeather();
if (weatherReport) {
const currentTemperature = weatherReport.degrees;
updateUI(currentTemperature);
}
The Hall of Shame
If you find these in your codebase during a code review (or your own PR), flag them immediately. They are "Context Vampires"—they suck the meaning out of your code.
data (What kind of data? Use userProfile or transactionList)item (Which item? Use cartItem or notification)flag (True means what? Use isVisible or hasAccess)arr (Array of what? Use activeUsers)
Stop writing code for the compiler. Start writing code for humans.
This article was an excerpt from my handbook, "The Professional Junior: Writing Code that Matters."
It’s not a 400-page textbook. It’s a tactical field guide to unwritten engineering rules.
👉 Get the Full Handbook Here
