The Code We Leave Behind
.jpeg)
Grace Hopper's keynote at AWS re:Invent 2025
Rear Admiral Grace Hopper (1906-1992) pioneered compiler theory and made programming accessible to everyone. She believed that the most dangerous phrase in any language was "we've always done it this way."
This is Part 3 of an ongoing series imagining Grace Hopper reviewing modern Python code. What would she say to 10,000 developers at the world's largest cloud computing conference?
The stage at AWS re:Invent is enormous. Ten thousand developers fill the convention hall, laptops glowing in the dimmed lights. The screen behind me—a wall of pure light—displays a single line of code in stark white text on a black background.
I'm 119 years old, technically. My knees protest every time I stand, but my mind is as sharp as it was in 1952. And I have things to say.
"Good morning," I begin. "I'm Grace Hopper, and I'm here to talk about the code you'll never see again."
The Code That Haunts Us
The screen changes.
def proc(d):
r = []
for x in d:
if x > 0:
r.append(x * 2)
return r
"This is code I saw last week," I say. "Someone wrote it, committed it, and moved on. They understood what it did. The question is: will you?"
I let the silence build.
"Here's what I know about this function: it processes something. It returns something. Beyond that?" I gesture at the screen. "I'm translating. I'm guessing. I'm working."
The next slide appears.
def double_positive_values(numbers):
doubled = []
for value in numbers:
if value > 0:
doubled.append(value * 2)
return doubled
"Now I don't have to guess. The function tells me its purpose. The variable names explain the logic. I can audit it, extend it, or fix it without hunting down the original author."
A hand goes up in the front row. A young engineer.
"But isn't the first version more efficient? Less typing?"
"Efficient for who?" I ask. "For you, writing it once? Or for the five engineers who will read it a hundred times over the next three years?"
The Real Cost
I step away from the podium.
"Let me tell you about cost. When I started programming, computer time was expensive. We optimized for the machine because machine time cost thousands of dollars per hour. Developer time was cheap."
The screen shows a new slide: a graph with two lines crossing.
"Today? That's reversed. Your salary costs more per hour than the cloud compute you're running. By a lot. So when you write cryptic code to save a few characters, you're optimizing for the wrong resource."
I pause.
"Every time someone opens your code and has to spend five minutes figuring out what proc means, that's money. Every bug that lives longer because the code wasn't clear? Money. Every new team member who takes a week longer to onboard because your codebase reads like a cryptography exercise? Money."
A low hum of agreement spreads through the crowd, like a shared "Aha!" moment rippling from front to back. I have them.
The Path Forward
"So we've established the cost of unclear code," I say. "Now, how do we get back to the good work? How do we build a legacy we can be proud of?"
I step back to center stage.
"Here's what I'm asking you to do: Write code that explains itself. Not occasionally. Not when you have time. Always."
The screen fills with principles:
Name variables for their purpose, not their type:
Not user_dict — just user
Not data_list — just transactions
Name functions for what they do, not how they do it:
Not calc — calculate_monthly_payment
Not proc — process_pending_orders
Write conditionals that read like sentences:
Not if x and y and not z
But if user_is_authenticated and has_permission and not is_suspended
"I'm not asking you to be verbose," I continue. "I'm asking you to be clear. There's a difference."
The Question of Standards
Someone calls out from the middle section: "But what about team standards? Our style guide says to keep names short."
I smile. I was waiting for this.
"Standards are tools, not laws. If your standard makes code harder to understand, change the standard. I've been changing standards my entire career."
I walk to the edge of the stage.
"When I built the first compiler, people said it couldn't be done. When I advocated for English-like programming languages, they said computers couldn't understand English. When I pushed for standardized languages, they said every company needed their own."
"They were wrong every time. Not because they were foolish, but because they were defending what they knew. 'We've always done it this way' is not a reason. It's an excuse."
The Legacy We Choose
The lights come up slightly. I want them to see me clearly for this part.
"Every line of code you write becomes part of a legacy. It will outlive your time on the project. It will outlive your time at the company. Some of it might outlive you."
"The question is: what do you want that legacy to be? Code that only you understood? Code that required insider knowledge to decode? Or code that welcomed the next person, explained itself, and made their job easier?"
I return to the podium.
"I've spent my career making computers more accessible. Not just the hardware—the ideas. The programs. The languages. I believed then, and I believe now, that if programming is going to change the world, it needs to be something humans can understand."
The final slide appears behind me:
Write code for the human who reads it next.
That person is always more important than the machine that runs it.
The Standing Ovation
The hall erupts. Ten thousand developers on their feet. Some are nodding. Some are already pulling out phones to take pictures of the principles on the screen.
I raise my hand for quiet.
"One more thing," I say. "That junior developer who asked about efficiency? You're going to be a senior developer someday. When that happens, remember this moment. Remember what it felt like to question the conventional wisdom. And when someone junior to you asks why the code is written a certain way, give them a better answer than 'because that's how we've always done it.'"
"That's how we move forward."
The applause continues as I leave the stage. But before I go, I reach into my pocket and pull out something I've carried for decades: a piece of wire, about a foot long.
I hold it up.
"This," I say, "is a nanosecond. The distance light travels in one billionth of a second. I've been showing this to people since the 1960s to make the invisible visible."
I let them see it, this simple piece of wire.
"Now think about all the minutes, the hours, the years you save with clear code. Think about every bug caught faster, every feature built quicker, every new developer onboarded smoother. That's not nanoseconds. That's not even milliseconds. That's human time. That's life."
I place the wire on the podium.
"Make it count."
The hall erupts again. I'm already thinking about the next conversation. Because the real work isn't the keynote.
It's the ten thousand conversations that happen after, when developers go back to their teams and ask: "Should we be doing this differently?"
That's where change begins.
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