[efitz]

I really don’t like this idea if you are sharing this code base with anyone else.

I work in one of the magnificent seven and the culture here is codename crazy. Everything has code names, of course: every project, every release of every project, every component or subservice of every project, every internal tool, and often minor features that address some one-off problem in any of the above.

I am sure that these names solve some kind of brevity problem for the people on those immediate teams, but it is a nightmare for everyone else.

It is impossible to reason about or even understand have the statements made by members of other teams in a meeting or communication because every other word they use is a code name for something that you’ve never heard of and the name doesn’t bear any resemblance to what it represents. It drives complexity through the roof.

[tshaddox]

It depends whether the increased brevity is worth the decreased intuitiveness. Consider that all words and names are made up in order to trade intuitiveness for brevity.

[seabass-labrax]

Excellent point; I think there is also an analogy to be made with the linguistic distinction between synthetic and analytic languages. Broadly speaking, analytic languages feature longer sentences with lots of brief, generic words, whereas synthetic languages have shorter sentences in which each word encodes a complex idea (for example, using prefixes or vowel changes). English is towards the middle of the continuum, with both analytical and synthetic characteristics.

[GuB-42]

I prefer code names over acronyms. Like code names, acronyms are meaningless to the uninitiated, but for me code names are more memorable. Here, I don't know what "EPD" or "SAN" mean and these are terms I have to get familiar with when reading the code base, just like "kep". I get that EPD and SAN are probably familiar terms to chess people, but the idea there is never a code base where you don't have to get familar with some vocabulary.

Unlike acronyms, good code words have some emotions attached to them, maybe some backstory or theme. For example, Android versions are alphabetically ordered desserts, there is some consistency to it. When first told, you can picture it in your head, even taste it, this can help with memorization as it is not just a random 3-letter string. Even with the nonsensical "kep", it has a nice sound to it, and in fact, I have memorized it, it is a combination of a hmm... chess stuff and... san? (looking up) oh yes, EPD and SAN.

[radlad]

I have found Android codenames to be a nightmare. Docs will sometimes refer to a codename, a version, or an SDK level. Why do we need three pointers to the same thing?

[sph]

Ubuntu is the same, unless you happen to know the previous release and know they are in alphabetical order. Debian is even worse: not in order, no one ever uses the version number.

[technol0gic]

Those are abbreviations, not acronyms.

[snowe2010]

They are acronyms. Why do you think differently? And acronyms are abbreviations. If you want to argue more you could state they’re initialisms, but SAN is standard algebraic notation so it’s definitely an acronym, while EPD could be argued not, but instead to be an initialism. In any case Wikipedia says it’s not a settled matter so why even argue about it? https://en.m.wikipedia.org/wiki/Acronym

[onionisafruit]

I’m not OP, but I’ll answer the question for me. I think differently because I was taught differently in English class about 40 years ago. The wikipedia page makes a weak argument.

What do you think distinguishes an acronym from other abbreviations?

[xboxnolifes]

Acronyms and initialisms are formed by each of the first letters of a phrase. Acronyms are distinguished from initialisms by being pronounced as a word rather than saying each letter individually. Abbreviations are shortened words or phrases: apartment=apt., captain=cpt., corporation=corp., minute=min., etc.

[ncallaway]

I feel like that complaint is somewhat addressed by the blog post itself:

> Obviously don’t go crazy with it, but it’s a tool I’m happy to have added to the toolbox.

It sounds like your company culture has gone crazy with it, which, yea, I would think it would make it hard to reason about.

I think this kind of naming approach could be...reasonable in a shared code base, if used very sparingly and well documented.

[mlyle]

Yah. If your big project has 2 kinds of objects, handles, designators, whatever that are used frequently... and their alternative english names are awkward, long, and/or misleading... give them a short pronounceable name. I endorse this 100%.

Don't do it 15 times, though, because then it's going to slow down onboarding more than the benefit you get.

[marcusbuffett]

Oh god yeah I’ve been in this situation too. Working at Apple it was like “is everyone in this meeting cleared for Tigris?” And you’d be like “I don’t know, what the hell is Tigris”, and then it turns out after you check your clearances it’s just iOS 13, which is obviously no mystery that after 12 there will be a 13. Just call it that!

Nothing was named according to what it did either, I think our deploy tool was Carnival? Just codenames everywhere

[euoia]

In general I completely agree that code name overload is dreadful. But I think in this case, where this pair is so fundamental and used so frequently in the codebase, I think I would probably permit it. Beware codename creep.

[boredtofears]

I dunno carnival seems like an apt name for a deploy tool at some of my past jobs.

[BWStearns]

That's definitely a possible failure mode, but I think it's preferable to having DataProcessingWorker, IngestService, ProcessingService, DataLoader, etc. Because, you eventually end up with all of these names and it's just as hard to guess what happens where as if they were named after fruits.

At least for me having too many names that are nearly semantically identical is worse than names that are a little (or even a lot) weird. We stare at names all day and if everything is named `YourCompanyNameMessageDataProcessingService` searches get annoying and it's easy for your eyes to start to glaze over.

If you name stuff like, say, Shucker, you have to ask "wait, wtf is the Shucker service?" Someone explains "It unwraps the GRPC messages and puts the contents on a queue. It's like shucking an oyster I guess? Yeah, we know it's a dumb name." But now you have a unique handle that's not likely to collide with other services.

If you can find a straight laced informative descriptive name that's unlikely to collide in the future that's great. But I'd take a funky name that immediately makes sense once you explain it (reference/pun/acronym whatever) over some 2010s java-class-name-looking beige blob of text any day.

[FridgeSeal]

I’m also in agreement with this.

Give me unique and memorable over generic-looking-with-the-merest-bit-of-information.

Used to work at a place where every repo, every service, etc was all CompanyShortNameThingDoerServiceRequester and similar, surprisingly unhelpful. I don’t want the 100th CompanyDataIngesterService because they all blur into one.

At least if someone goes “oh yeah the Oyster service will give that to you” we know precisely which one we mean.

[adzm]

In my personal experience, libraries/code that is widely applicable is what benefits from having a great weird fun name. No one wants to deal with a one off service you decided to name Hecate with no reason or broader appeal.

[drewcoo]

> It is impossible to reason about or even understand have the statements made by members of other teams in a meeting or communication because every other word they use is a code name for something that you’ve never heard of and the name doesn’t bear any resemblance to what it represents

Then it's working. That is exactly the point of code names.

[diob]

It's one of my big issues with lots of things, even outside tech.

What's that? Oh, so it's like this. Why not call it that?

[lawn]

I've only worked at a company with around 300 employees and I've still struggled with this issue.

[readthenotes1]

I figure it would be awful hard to communicate without the semantic shortcuts that comprise a vocabulary