Some months ago I wrote a proposal for handling how things get named. It was a bit tongue-in-cheek (in a “just kidding…unless you’re gonna do it” sort of way), but more recently I’ve been giving some thought to how I might actually go about the business of being the Naming Tsar. For at least some things I think I’d take the approach of “nonsense names” - names that have no semantic meaning attached, that have nothing to do with the thing they represent. Fruits, flowers, perhaps colors - simply select a category with some reasonable selection of names (I’d imagine something like 2-3 dozen would do), enumerate them, and then when it comes time to name the next thing just pop the next one off the list. Android does this with their release codenames using sweets - Gingerbread, Jelly Bean, Nougat, etc.

There are several upsides to this approach. Having a predetermined list with a specific category does away with the up-front cognitive load of having to come up with a “good” name, both by pre-seeding the list and by removing the inbuilt assumption that in order for a name to be “good” it needs must be superlatively descriptive of the object it’s naming. It could also circumvent Holy Wars concomitant with deriving a naming standard, and the abject misery of having multiple competing naming “standards”. I say “could” because I can also imagine a dystopian Zoom call arguing whether to use “muscle cars” or “Transformers”. (“Next order of business: we’re limiting ourselves to just Decepticons, right? Because if Autobot names are on the table then I will escalate this.”)

A secondary benefit of this scheme is that it gives names “room to breathe” - opportunity to evolve over time with the named thing. Take Google, for instance. If you asked someone in 1999 what Google was (and if they had actually heard of it), that person would’ve said “a search engine”. In 2022, that may be one response…but you might also get “an email provider”, “an app store”, “a cell phone company”, “where all my documents are”, “how I pay for things without using a credit card by waving my phone in vaguely the direction of a cashier”, etc. Possibly an even better example is Amazon. Imagine the cognitive dissonance of ordering everything from toilet paper to ball bearings to on-demand movies to pantry goods - with two-day-delivery! - from a site named “books.com”.

I suppose one downside to this approach is that one would no longer be able to glean any information about a thing by simply glancing at its name. Take “fire pit”. Once you’ve heard the name you know what it is, what it’s for, even how to make one and use it. …but contrast that with “internal combustion engine”. There are some pretty good hints/clues in the name about what it’s for and roughly how it achieves its purpose, but you’re going to need a whole lot more detail to understand how it actually works, and a whole lot more to grok how to effectively build/maintain one. I guess my point is that in technical fields sometimes you have to RTFM…and we happen to work in a decidedly-technical field.

Also, this is really only a “first time” problem, and one with copious currently-existing examples. The uninitiated might ask “What’s Kafka?” …but once you’ ve internalized that it’s “a distributed event streaming platform with at-least-once delivery semantics” then you’re pretty much good to go.

To round this out with a bit of a digression: I’m imagining Kafka Bros coming at me with “Nuh-uh! It’s at-most-once if you ! And you can get exactly-once if you just <do a whole bunch more even more complicated stuff>!”

It’s okay, Kafka Bros. We needn’t quarrel.

I hear you, and you’re (sort of, mostly) right.