Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

Post reply on HN
Print view View original

381–390 of 498 posts

Re: Names should be cute, not descriptive

#381

Post by whatshisface »

feoren wrote: post #378
shkkmo wrote: post #371

Earlier quoted context omitted.

Of the three you mention, only "cholesterol" was actually named by an early chemist [0]. "Oil of vitriol" was first mentioned by an alchemist almost 1000 years ago but the term "vitriol" already existed to refer to some metal sulfates. "Salt" is much much older. [0] https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul

> first mentioned by an alchemist I was really hoping we'd all be mature enough to not have this petty argument over when people studying the properties of chemicals stopped being called "alchemists" and started being called "chemists". What year was that, exactly? Exactly. I need an exact year, so I don't make this "mistake" again, please. Because otherwise, I think "early chemists" is a perfectly accurate descripti…

The transition was gradual but did happen, and on one side you had a lot of pseudo-religious beliefs and on the other you had experimentation and the scientific method.

Re: Names should be cute, not descriptive

#382

Post by jakelazaroff »

throw__away7391 wrote: post #374

If you're going to do this, why not also do it for classes, function, and variables? The the reasons you wouldn't do that are also reasons you shouldn't do it for services. A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "becau…

> If you're going to do this, why not also do it for classes, function, and variables?

Because those are easy to change. Service names inevitably get strewn across who knows how many other services and pieces of infrastructure.

Re: Names should be cute, not descriptive

#383

Post by aendruk »

rhacker wrote: post #329

While I don't agree with the author AT ALL. I think products need two names: a marketing name and a code name. I was at a company that kept renaming the marketing name. And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector. I kept trying to tell people that the marketing name is going to change all the time and that…

I tried this once and marketing latched on to my deliberately stupid code name and used it for the public release. My protest was unable to sway them.

Re: Names should be cute, not descriptive

#384

Post by beckingz »

xeyownt wrote: post #187
jeroenhd wrote: post #118

Earlier quoted context omitted.

Would this be easier if you needed to integrate with user-provider-service, timestamp-conversion-service, image-storage-service (which also stores videos these days, though HEIFF and h.265 has obviously been moved to iOS-image-storage-service so customers can be billed for the special software that requires patents) to upload a signed SecuredApplicationPackage file to InternalExternalSoftwareManager so that it can be…

Couldn't have said it better. Overall, common sense should be the rule, not "always descriptive / always cute".

The thing about common sense is that sense isn't common.

Also, more accurately, the environmental information used for our common sense naming changes out from under us.

Re: Names should be cute, not descriptive

#385

Post by TylerLives »

throw__away7391 wrote: post #374

If you're going to do this, why not also do it for classes, function, and variables? The the reasons you wouldn't do that are also reasons you shouldn't do it for services. A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "becau…

The difference is that a service might do many things, while functions and variables usually have smaller purpose.

Re: Names should be cute, not descriptive

#386

Post by trynewideas »

I worked in a non-engineering role at a place that used cutesy names for almost everything: meeting rooms, engineering teams, internal tools and libraries, events. Nothing was descriptive, and even just fundamental roles and responsibilities were institutional knowledge. (They were "documented", but nobody was responsible for updating the docs when people left/moved/were added.)

So when a customer complaint about messaging came across my desk, I'd first have to figure out which team to go to: Ice Cream, Teddy Bear, Jetski, or Pineapple.

What parts of the product does Ice Cream work on? Do they work on the messaging protocol? Or was it the app server? Oh, didn't you hear, Jetski took on the app server last month and this week they're spinning off the messaging protocol into a new team, Applejack. Now Ice Cream's only responsible for user authentication.

Okay! Cool, so who's in Applejack? The Software Mage for the BrokenLighthouse library, which implements the messaging protocol? No, actually it's the Product Master for BrokenLighthouse's replacement, WorkingSignal. BrokenLighthouse maintenance is still with Ice Cream.

Okay! So is the Software Mage for BrokenLighthouse still on Ice Cream, like the directory (sorry, the Cast of Characters) says? No, they transferred to Jetski with the app server, sorry, I mean AppleBucket team.

Okay! I'll just join #jetski... wait, it doesn't exist anymore. Oh, right! Now that they have AppleBucket they renamed to Appleski.

Okay! I'll just join #appleski. (Damn it, Slack, don't autocomplete it to #applejack or #applebucket-feedback.) "Hey, I've got a support ticket for a messaging protocol issue, can someone help?"

> Sure, we're meeting in Batman on that right now! Come join us!

Okay! Where's Batman? The office has two floors, Cartoons and Comics, and each is divided into four themed quadrants, and each room is named after someone in one of those quadrants. So Cartoons is split into Adult Swim, Looney Tunes, Simpsons, and Disney, and Comics is split into DC, Marvel, Dark Horse, and Newspaper.

Counterintuitively, I loved watching Batman:TAS as a kid before I knew it was a comic book, so I always wind up wandering around WB looking for Batman. "Where's Batman?" Oh, Batman's in DC, upstairs.

Okay! I enter Batman and find Appleski talking about BrokenLighthouse.

"Hey! Is this where I can ask a customer question about the messaging protocol?"

Blank stares.

"Sorry. Is this where I can ask about this BrokenLighthouse error message that just says 'AppleBucket is refusing LightBeams from BrokenLighthouse due to a misconfigured PineappleSkin'?"

> Oh sure! That's just the message protocol saying there's a syntax error in the config YAML. The v2 protocol will switch to JSON and provide more detailed feedback.

Re: Names should be cute, not descriptive

#387

Post by feoren »

kerkeslager wrote: post #380
feoren wrote: post #361

Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course. Vitriol's correct name is "sulfuric acid". Salt's correct name is "sodium chloride" Cholesterol's correct name is "(1R,3aS,3bS,7S,9aR,9bS,11aR)-9a,11a-Dimethyl-1-[(2R)-6-methylheptan-2-yl]-2,3,3a,3b,4,6,7,8,9,9a,9b,10,11,11a-tetradecahydro-1H-cyclopenta[…

There are so many straw man arguments in this post it's hard to play them apart. > Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course. That's not what happened, and nobody is saying that the chemical serialization is the "correct" name. The reality is that originally we didn't know the internal structure…

> The naming grew as our understanding of the function grew.

Yes! That's exactly it! You have accidentally made my point exactly. The name grows as the understanding of the function grows. And your understanding of what a given service or application should be doing is always growing and changing over time. So if your name is an encoding of the function, it will constantly change and grow, until it's as ugly and useless as Cholesterol's "true" name.

> Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol.

Yes! That's exactly it! Your CRM program doesn't need to know that your spell-checking service is also a translation service, and your international logistic program doesn't need to know that your translation service is also a spell-checking service. So the name "TextCheckerTranslator" is partially irrelevant to both. And what happens when you add a third function to it? It now can also do OCR. So now your CRM program, which only cares about the "checker" part, needs to be re-compiled or have its config changed because it now needs to call the "TextCheckerTranslatorOCR" service instead. Every downstream service has to be changed because of changes that have nothing to do with them! Just call it "Wordsmith".

> More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services.

Our understanding of chemicals changes, just like our understanding of which services should do what (and what that means) changes. But either way, if services are more likely to change, then all the more reason to use artificial names for them (rather than trying to encode all their purposes).

> Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson.

Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words. I agree the word should not be completely divorced from its use. SamuelLJackson would be a good name for a service which takes boring text and liberally inserts creative swear words into it.

> Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time.

We all treat "hiding details" important in code. If every part of my code depends on every other part of my code, then one change will mean 100 changes. The answer isn't "well, just make sure those 100 changes are super fast, and ignore the constant thrashing in your git history". The answer is standard programming practice of sharing only the details that are relevant to others.

Re: Names should be cute, not descriptive

#388

Post by throw__away7391 »

jakelazaroff wrote: post #382
throw__away7391 wrote: post #374

If you're going to do this, why not also do it for classes, function, and variables? The the reasons you wouldn't do that are also reasons you shouldn't do it for services. A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "becau…

> If you're going to do this, why not also do it for classes, function, and variables? Because those are easy to change. Service names inevitably get strewn across who knows how many other services and pieces of infrastructure.

It sounds like your deployment and provisioning infrastructure is sub-par. Why would you shove unrelated functionality into the same service? Especially to the point where you can't even choose a descriptive name for said service.

Re: Names should be cute, not descriptive

#389

Post by dctoedt »

reassembled wrote: post #161

What annoys me is when internal code names are used all over the place throughout the code base. Sure it might make it easier for those steeped in years of company culture to navigate the code, and provide a slightly more playful company culture, but it makes it an absolute nightmare for a beginner to find things. Furthermore, I often see companies use trademarked words for internal code names, which could lead to pr…

> I recall reading that such use of trademarks for internal code names led to legal issues for a company.

Apple Macintosh, perhaps?

https://www.macworld.com/article/669214/how-the-macintosh-go...

Re: Names should be cute, not descriptive

#390

Post by throw__away7391 »

TylerLives wrote: post #385
throw__away7391 wrote: post #374

If you're going to do this, why not also do it for classes, function, and variables? The the reasons you wouldn't do that are also reasons you shouldn't do it for services. A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "becau…

The difference is that a service might do many things, while functions and variables usually have smaller purpose.

Surely though in any case either there is some unified theme or purpose for a service or you are building a monolithic application which can just have the same name as the product.

If you are putting random functions into a service to the point where you can't even pick a descriptive name, that sounds like you've got bigger problems.

Post reply on HN