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

391–400 of 498 posts

Re: Names should be cute, not descriptive

#391

Post by feoren »

whatshisface wrote: post #381
feoren wrote: post #378

Earlier quoted context omitted.

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

And this distinction is important enough to you that you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists", and if they don't, you're going to correct them? Even if it's irrelevant to their main point? That's the discourse we want on here?

Everyone had pseudo-religious beliefs back then! Can we not talk about "early astronomers" who were studying the movements of stars and planets, if they also believed in other weird shit? Who cares if they were studying the stars in order to sacrifice goats at better times?

Re: Names should be cute, not descriptive

#392

Post by dctoedt »

When U.S. law applies, trademark lawyers urge companies to find "suggestive" names — requiring insight to realize "ah, that's what this is!" — as the "sweet spot" to get the most bang for the buck in marketing while still being legally-protectable. (Examples: Coppertone for suntan lotion; Greyhound for bus-transportation services; Energizer for batteries.)

"Merely descriptive" marks can't be protected legally without proof that they've acquired "secondary meaning," e.g., through widespread advertising, going viral, etc.

"Coined" or "fanciful" marks such as Reebok and Kodak, and "arbitrary" marks such as Lotus for software, are protectable, but they don't do much good in advertising, at least not initially, because customers don't know what product or service is.

Self-cite: https://www.oncontracts.com/startup-law/#Trademarks_look_for...

Usual disclaimer: I'm a lawyer but not your lawyer.

Re: Names should be cute, not descriptive

#393

Post by mlyle »

throw__away7391 wrote: post #388
jakelazaroff wrote: post #382

Earlier quoted context omitted.

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

> Why would you shove unrelated functionality into the same service?

Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients. And perhaps answering queries about that or naming ends up becoming its most important job... even though it was originally just a simple broadcast service.

Then, later, you end up not even using the broadcast functionality.

Code drifts and changes. Top level names are more likely to be lies than variable or function names, because the latter are easy to change.

Re: Names should be cute, not descriptive

#394

Post by jakelazaroff »

throw__away7391 wrote: post #388
jakelazaroff wrote: post #382

Earlier quoted context omitted.

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

> It sounds like your deployment and provisioning infrastructure is sub-par.

If you want to add supporting details to that — like, any at all — then we can have a discussion. The rest of your comment doesn't actually relate to anything I said.

Re: Names should be cute, not descriptive

#395

Post by wvenable »

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…

In my opinion, one of the top criteria for a good developer is that they don't fear making changes. If a function has changed purposed, a good programmer will rename that function even if it's across hundreds of files.

A poor programmer will see that as wasted effort and not do it.

From my experience working with a good infrastructure team, good system administrators do the same sort of thing. It's easy to not change names but in 10 years you have no idea what you're looking at. Our team is constantly moving stuff around and renaming things when it makes sense to do it.

Re: Names should be cute, not descriptive

#397

Post by dlivingston »

kevincox wrote: post #336
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…

100%. I was at a company and they kept renaming the internal name to match the marketing name. We had 3 names for some older tech and 2 names for the less than a year old service. I strongly recommended that we should adopt the original name as a "codename" and use it for code and internal technical documents. Marketing should absolutely have full control over the user visible name. But technology has different needs…

Related-ish, but Apple's macOS APIs are peppered with references to NeXTSTEP. I find this charming. For example, NSView (spelled out - NextStepView).

https://developer.apple.com/documentation/appkit/nsview

Re: Names should be cute, not descriptive

#398

Post by ryanmcbride »

Last company I'm worked for named all their services after Toy Story characters and no one knew what anything did. "So Woody talks to Buzz that lives on the client's server and then pushes the data to Pizza Planet where Sarge queues it up to Bopeep". I hated it

Re: Names should be cute, not descriptive

#399

Post by dlivingston »

aendruk wrote: post #383
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.

If comfortable disclosing, what was said code name?

Re: Names should be cute, not descriptive

#400

Post by seti0Cha »

feoren wrote: post #355
PragmaticPulp wrote: post #10

Cute names are fun when for a few special things here and there. Cute names are a nightmare when a company has accumulated hundreds of quirkily named things that you have to memorize just to navigate through the basics of trying to get your job done. New hires suffer the most. It’s an extra layer of company-specific jargon that you have to learn to even begin to understand what your peers are talking about.

> Cute names are a nightmare when a company has accumulated hundreds of quirkily named things that you have to memorize Now imagine trying to navigate hundreds of things that are descriptively named wrong . The argument isn't between (A) cutesy names, and (B) accurate descriptive names. B is obviously better. But that's a fantasy world that doesn't exist. The argument is between A and (C) descriptive names that rot o…

No, the alternative is having 100s of things that are basically right, with a few that are misleading. I'll take that any day over all cute names, because I only have to remember the exceptions. Not theoretical, I've been in that situation. Also, purpose drift is technical debt. Using meaningless names is just a way of hiding that debt. A service that doesn't match it's name has evolved into a bad place and needs to be refactored. You want to be able to see that.
Post reply on HN