DEV Community

Cover image for Stop "Saving Keystrokes". I Spend 3 Seconds to Save 3 Hours
Doogal Simpson
Doogal Simpson

Posted on • Originally published at doogal.dev

Stop "Saving Keystrokes". I Spend 3 Seconds to Save 3 Hours

#beginners #javascript #career #programming

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)

// 'data' could be anything. 
// We have to mentally map 'data' to 'Weather API Response'
// and 'v' to 'temperature value'.
const data = getInfo();

if (data) {
  const val = data.v;
  // If I read this line in isolation, I have zero clue what is happening.
  updateUI(val); 
}
Enter fullscreen mode Exit fullscreen mode

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)

// We know exactly what this is without seeing the rest of the file.
const weatherReport = fetchWeather();

if (weatherReport) {
  const currentTemperature = weatherReport.degrees;

  // This line reads like an English sentence.
  updateUI(currentTemperature);
}
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)