Which one lands faster in your head:
Nano Banana or Model 2.5 Flash Image Native?
Exactly.
Same energy as Sony WH-1000XM versus AirPods Max.
One is a name you can say.
The other is a barcode that escaped its spreadsheet.
Google runs billions of lines of code and hundreds of services.
They call things Spanner, Chubby, Borg, Nano Banana.
Nobody’s confused. Nobody’s screaming in meetings.
Seems fine.
Now try renaming Chaos Monkey to something rational like Failure Injection Service.
You lose recall. You lose story. You lose the smile.
Names aren’t documentation.
They’re an abstraction — a handle.
Something you can hold without holding the whole thing.
There are only two kinds of people who ever use your service’s name:
the people inside it, and the people around it.
Only one group uses it every day.
Inside a team, names are spoken in standups, PRs, Slack threads, deployment channels.
If you call something Asset Configuration Service, by Wednesday you’ll hear:
“I’m fixing that asset thing.”
“Did the asset config deploy?”
“Which one, media or third-party?”
By Friday, you’ve corrected everyone and yourself a dozen times.
Internal speech compresses. It always does.
People speak faster than they think, and names follow speech, not the other way around.
So the real job of naming is to give that compression a safe landing.
A short, durable handle that doesn’t split.
A word that can survive inside jokes, abbreviations, and tired 7 PM standups.
That’s your audience. That’s who you optimize for.
Then there are the people around your system.
They use your thing once in a while as part of their workflow.
Here’s the descriptive fantasy version:
We use Configuration Manager for configuration,
Command Line Interface for CLI,
WebSocket Connection Manager for websockets,
Permission Service for permissions,
and Job Queue Broker for background jobs.
Feels clean. Rational. Boring.
But the cost didn’t disappear. They still have to open the docs and figure out which configuration, what scope, what boundaries.
Now the fun version:
We use Viper for config, Cobra for CLI, Melody for websockets, CASB for permissions, Asyncq for jobs.
They’ll still look it up, but at least the names don’t collide, and they travel better in conversation.
No one confuses Viper with Melody.
The lookup cost for external users is infrequent.
The speaking cost for internal teams is daily.
Optimize for the people who pay rent with that name.
Descriptive names trade local comfort for global collision.
They buy a short-term feeling of clarity for the people who think they’re explaining something,
at the expense of everyone who has to live with the word forever.
Google figured this out a long time ago.
They have Chubby, Spanner, Borg, Dremel, Nano Banana.
No one there says “I have no idea what Borg does.”
Docs explain. Boundaries define. Names travel.
Someone will always say, “But what about new engineers? Descriptive names help them onboard.”
No, they don’t. They help for two days.
Then they’re reading code, diagrams, and docs anyway.
The cost of understanding a system isn’t in the name. It’s in building context.
And you don’t erase that cost with more syllables.
Everyone loves “Rational descriptive names.” Until they don’t.
At first, it feels clean. Rational. Safe. You get a Configuration Service. Great. Another team also needs one — Configuration Service.
Now you’ve got ThirdPartyConfigurationService, NativeConfigurationService, and AudioAssetConfigurationService.
Congratulations. You’ve invented adjectives.
The boundary stays fuzzy, the names get longer, and nobody knows if they should put their config in the “core” config or the “assets” config. That’s collision. It happens fast because there are only so many words people reach for. “Config.” “Core.” “Common.” “Service.”
Rational descriptive space is tiny and soon everyone names things similarly.
Naming something NailBeater sounds rational until the thing stops beating nails.
You tap chisels, crack tiles, set dowels, pull bent nails.
Now it’s a NailBeaterWithUtilityFunctions.
Or NailAndMiscToolService.
Or you give up. You rename it back to Hammer and move on.
The point: the name should survive the next context change.
“Hammer” is a handle, not a spec.
The docs can explain what it really does.
Same for services — the name should point to a bounded thing, not narrate its life story.
It is fun. For God’s sake.
A good name sparks joy…
You get to create a tiny world and live in it.
It’s nice to say “I’m working on Hydra” instead of “the internal media configuration pipeline service.”
It gives the team a flag.
It travels.
It makes the day slightly less gray.
And no, this isn’t a call for anarchy.
Don’t start naming your variables after your pets.
Don’t ship fuzzyWuzzyFunction() to prod.
This is about projects and services — the stuff people mention in standups, write in Slack, and live inside for months.
Of course, it also depends if you work for a Microsoft or a Google.
People have their preferred taste of fun.
All I’m saying is — it can be a small human signature of the org’s culture.