Grace Hopper Walks Into a Code Review
.jpeg)
What happens when Grace Hopper reviews your code
Rear Admiral Grace Hopper (1906-1992) pioneered compiler theory and spent her career making programming accessible. She famously kept a nanosecond—a foot-long piece of wire—on her desk to make abstract concepts concrete.
This is Part 2 of an ongoing series imagining Grace Hopper reviewing modern Python code. What would happen if she walked into your team's code review?
The conference room at MegaCorp has everything: a massive screen, expensive ergonomic chairs, and seven developers who have no idea what's about to happen.
They're expecting a routine security audit. Something about "military protocol review" on their payment processing system. The invitation went out three weeks ago, signed by someone in compliance they'd never heard of.
What they're getting is me.
I'm here as a "consultant," they were told. They think I'm retired military reviewing their security protocols.
Close enough.
"Admiral Hopper, thanks for joining us," says the team lead, a sharp woman named Maya. "We're excited to show you our new payment processing microservice."
I settle into a chair and watch as she clicks through to their codebase. Let's see what we're working with.
The Presentation
"So we've optimized for performance," Maya begins. "Here's the main processing loop."
for i in range(len(txns)):
amt = txns[i].get('amt')
if validate(amt):
process(txns[i])
Six heads nod in approval. One junior developer—his name tag says "Chen"—looks uncertain but says nothing.
I let the silence sit for a moment. Then: "Walk me through what this code does. Pretend I've never seen it before."
Maya shifts. "Well, it loops through transactions and processes valid amounts."
"I see the loop," I say. "But tell me: what is i?"
"It's the index," someone offers.
"The index of what?"
"Of... the transaction?"
"Is it?" I lean forward. "When I read i, I learn that you're counting. But I don't learn what you're counting through. And txns—I assume that's transactions, but you made me assume. You made me translate."
The Question
Chen speaks up, hesitant. "Should we... name it transaction instead?"
"Show me," I say.
He steps to the keyboard.
for transaction in transactions:
amount = transaction.get('amount')
if validate(amount):
process(transaction)
"Read it aloud," I tell him.
"For each transaction in transactions, get the amount. If the amount is valid, process the transaction."
"Did you hear that?" I look around the room. "He just explained the code by reading it. No translation required. That's the goal."
Maya frowns. "But everyone knows what i means. It's standard."
"Standard for who?" I ask. "For the person who wrote it? For experienced Python developers? What about the new hire six months from now? What about Maya-in-February when she's debugging this at midnight and can't remember why she wrote it this way?"
The Pattern
"Let me show you something," I say, standing. "May I?"
Maya gestures to the keyboard. I pull up another section.
def calc(x, y, z):
tmp = x * y
res = tmp + z
return res
"What does this function do?" I ask the room.
Silence. Someone ventures: "Calculates something?"
"Exactly. You know it calculates. But calculate what? What is x? What is y? What is tmp?" I rewrite it.
def calculate_total_price(quantity, unit_price, tax):
subtotal = quantity * unit_price
total = subtotal + tax
return total
"Now what does it do?"
"It calculates the total price of items with tax," Chen says immediately.
"Right. And you knew that without me telling you, without a comment, without documentation. The code told you itself."
The Resistance
"But isn't that verbose?" asks one of the senior developers. "We're trading brevity for... what, being obvious?"
"You're trading mystery for clarity," I correct. "Yes, it takes more characters to write quantity instead of x. But how many minutes will those extra characters save the next person who reads this code? How many bugs will they prevent?"
I sit back down. "I've been writing code since you had to literally wire the instructions into the machine. I've seen every argument for cryptic variable names. And I've watched every single one of those arguments age poorly."
"We thought we were being efficient with punch cards. We thought assembly mnemonics were clear enough. We thought nobody but programmers would ever need to read code." I pause. "We were wrong every time."
The Moment
Maya is quiet, looking at the screen. "So the rule is... what? Always use full words?"
"The rule is: write for the human who reads it next," I say. "Sometimes that means i is fine—if you're doing pure mathematics where i is conventional. But most of the time? Most of the time you're not counting, you're processing users or transactions or orders or records. Real things. Give them real names."
Chen is nodding. Maya pulls up another file, this one full of data, result, temp.
"How would you fix this?" she asks.
"I wouldn't," I say. "You would. You know what these variables represent in your business logic. I don't. The question is: does your code explain it to someone who doesn't know?"
The room is quiet. I can see them looking at their own code differently now.
The Resolution
"Admiral Hopper," Maya says slowly, "we've been writing code that we can decode. Not code that explains itself."
"Yes," I say simply.
"That's going to be a lot of refactoring."
"It is. But here's the thing about clear code: it makes every change after this one easier. Every bug hunt. Every feature addition. Every new team member." I stand. "You're not writing code for the compiler. The compiler doesn't care what you name things. You're writing it for every person who will ever need to understand it."
Chen is already making notes. "Should we update the style guide?"
"Update it," I say, heading for the door. "But remember: the goal isn't a new set of conventions to follow blindly. The goal is code that speaks for itself."
I pause at the door. "One more thing. That junior developer who was uncertain at the start? He was right. Listen to the people who ask 'why.' They're the ones still thinking."
Write code for the human who reads it next. That person is always more important than the machine that runs it.
Next in the series: Grace Hopper takes the stage at AWS re:Invent 2025.
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