5 ms·

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

by efitz 2y ago

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.

drewcoo 2y ago
> 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.
marcusbuffett 2y ago
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 2y ago
  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 2y ago
  I dunno carnival seems like an apt name for a deploy tool at some of my past jobs.
tshaddox 2y ago
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 2y ago
  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.
diob 2y ago
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?
ncallaway 2y ago
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 2y ago
  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.
BWStearns 2y ago
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 2y ago
  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 2y ago
    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.
GuB-42 2y ago
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.
- technol0gic 2y ago
  Those are abbreviations, not acronyms.
  - snowe2010 2y ago
    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 https://en.m.wikipedia.org/wiki/Acronym
    - onionisafruit 2y ago
      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?
      - 2y ago
readthenotes1 2y ago
I figure it would be awful hard to communicate without the semantic shortcuts that comprise a vocabulary
lawn 2y ago
I've only worked at a company with around 300 employees and I've still struggled with this issue.

by efitz 2y ago

drewcoo 2y ago

> 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.

marcusbuffett 2y ago

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 2y ago
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 2y ago
I dunno carnival seems like an apt name for a deploy tool at some of my past jobs.

tshaddox 2y ago

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 2y ago
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.

diob 2y ago

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?

ncallaway 2y ago

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 2y ago
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.

BWStearns 2y ago

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 2y ago
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 2y ago
  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.

GuB-42 2y ago

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.

technol0gic 2y ago
Those are abbreviations, not acronyms.
- snowe2010 2y ago
  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 https://en.m.wikipedia.org/wiki/Acronym
  - onionisafruit 2y ago
    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?
    - 2y ago

readthenotes1 2y ago

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

lawn 2y ago

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