What Would Grace Hopper Think of Your Code? (A 2:47 AM Review)
Why meaningful variable names matter more than convention
Rear Admiral Grace Hopper (1906-1992) pioneered compiler theory, led the team that created COBOL, and spent her career fighting to make computers accessible to humans.
Imagine if she could see what we're writing now. Imagine if she sat down at a laptop in 2025, opened a pull request, and saw what passes for "readable" Python code.
This is what she might think.
The nanosecond sits on my desk—eleven point eight inches of wire, the distance light travels in a billionth of a second. I keep it there to remind generals why satellites can't phone home instantly. Tonight, I'm looking at it for a different reason: to remind myself that clarity is measured in understanding, not convention.
It's 2:47 AM. I'm reviewing a pull request. Again.
First, I saw this loop. It's a classic.
for i in range(len(users)):
print(users[i].name)
That line of code, and thousands like it, is why I'm still up at this hour. I see this and my blood pressure rises.
Deep breath.
We taught them this. We actually sat in classrooms and taught them that i is just what you use. Like it's the Lord's own commandment handed down from Mount Mainframe.
The Thing About i
Here's what nobody tells you: i made sense when we were counting through punch cards. When the "thing" you were iterating over was so abstract that giving it a name would've been silly. But you're not processing punch cards. You're processing users. Human beings with names and email addresses and preferences.
for user in users:
print(user.name)
Look at that. It reads like English. It tells you what it does. You don't have to translate from index-land to human-land in your head.
I didn't spend years making COBOL readable just so you could go backwards into cryptic nonsense because "that's how it's always been done."
The Meaningless Name Problem
I see this one constantly:
tmp = calculate_total(items)
final_price = tmp * (1 - discount)
What is tmp? What does it represent in the actual problem you're solving?
You spent mental energy calculating a total. You wrote a whole function for it. And then you threw away all that meaning by calling it "temporary."
Here's how you write it when you're thinking for the human:
subtotal = calculate_total(items)
final_price = subtotal * (1 - discount)
Same number of characters. Infinitely more information. The code now tells a story: we calculate a subtotal, then we apply a discount to get the final price.
This isn't hard. This is just... thinking.
The Convention Trap
Someone's going to read this and say, "But Admiral Hopper, everyone knows what i means! It's standard!"
Sure. They'd also say, "We've always done it this way." That's always been my least favorite phrase.
And everyone "knew" that computers had to speak in ones and zeros. Everyone "knew" that business people could never write their own programs. Everyone "knew" assembly was as good as it could get.
I've heard "everyone knows" my entire career. Usually right before we change everything.
The goal isn't to write code that other programmers can decode. It's to write code that humans can read. There's a difference.
What I Actually Care About
It's almost 3 AM now. I'm an old woman arguing with a computer screen about variable names. You might wonder why I care.
Here's why: I remember when programming was priesthood. When only the initiated could approach the machine. When we spoke in arcane symbols and everyone else just had to trust us.
I spent decades fighting that. Making compilers. Advocating for English-like syntax. Arguing that if we wanted computing to change the world, we had to make it accessible.
And accessibility doesn't stop at syntax. It lives in every variable name, every function, every line of code you write.
When you name a variable i, you're making a choice. You're saying: "Understanding this requires insider knowledge. You need to know the convention."
When you name it user, you're making a different choice. You're saying: "This code explains itself. Come on in."
The Real Convention
There's only one convention that matters: write code for the human who reads it next.
Maybe that's a junior developer on their first week. Maybe that's you in six months when you've forgotten why you did this. Maybe that's me, at 2:47 AM, trying to figure out if your algorithm is correct or just conventional.
The nanosecond on my desk is about making the invisible visible. Making the abstract concrete. Helping people understand.
Your variable names should do the same thing.
Not because I say so. Not because it's a new convention to replace the old convention.
Because a ship in port is safe, but that's not what ships are built for. And code that merely works is fine, but that's not what code is built for.
Code is built to be understood.
Make your code explain itself. That's not a courtesy. That's the job.
Now if you'll excuse me, it's 3:14 AM, and someone just used foo and bar in production code.
Unbelievable.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment