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

481–490 of 498 posts

Re: Names should be cute, not descriptive

#481

Post by mrweasel »

wlonkly wrote: post #467
mrweasel wrote: post #139

Earlier quoted context omitted.

The whole Cloud Native Landscape is full of BS like this: Kong, Skipper, Harbor, Calico, Helm, Linkerd, Flannel, you add the next 50 or so project that I forgotten. It makes the entire thing really complex to navigate, and impossible to talk to others about, because they may have plugged in some network you don't know, but you don't know that it's a network, because the name provides zero clues. Or there might be clu…

Some of those have companies attached, which have interests in a unique, memorable, and protectable name. Others are definitely just cute though. That said, I have to object to including linkerd. It links services together, and it's a daemon. Can't get much clearer than that.

The problem with linkerd is that we already use the word "linker" and have an established nomenclature for adding a "d" to indicate a daemon. While linkerd might be a daemon, it's not a linker daemon.

Re: Names should be cute, not descriptive

#482

Post by Scea91 »

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…

Would you extend this to all names and not just product? I attempt to push domain driven design and one of the principles is that a single concept should be called by a single name. It all works well until product management decides to unilaterally push renaming of of concept in UI for vague 'market' reasons...

Re: Names should be cute, not descriptive

#483

Post by ourmandave »

deltarholamda wrote: post #462
tremon wrote: post #301

Earlier quoted context omitted.

It depends on scale. If you have 3 servers that you manage individually, you name them like pets. If you have 3,000 servers that you manage through automation, you enumerate them like cattle.

Sure, I get that. Not many do that, but they still name their handful of servers "EDG-12-XY-NY-001-WTF". When it would be so much better if it were named "Doug".

You'd be taking support calls, "WTF NY?"

Re: Names should be cute, not descriptive

#484

Post by taneq »

Spivak wrote: post #262
causi wrote: post #149

Earlier quoted context omitted.

Modern generic-ass naming schemes are absolutely infuriating. I hear someone say "oh yeah, it's been easier since we moved our Bluē processes into Laundr containers which we manage through a mix of Bicycle and Parakeet" and my lungs are not big enough for the sigh I want to emit.

Well yeah because those things are all specific implementations of services. They need to have unique names for preciseness. "Oh yeah we've moved our app processes into containers which we manage with our workload scheduler and discovery service." What is the app? What kind of containers? What kind of scheduler? What kind of discovery service? Guess you just have to know. Verses. "Oh yeah we moved our frontend Rails…

They should name themselves clearly for the situations in which they offer compelling performance advantages. If that’s an issue then maybe they don’t deserve names.

Re: Names should be cute, not descriptive

#485

Post by danmur »

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…

Yep. All my personal projects I give a name that's related to the subject but will never be a public name. Helps a lot with naming paralysis.

Re: Names should be cute, not descriptive

#487

Post by feoren »

kerkeslager wrote: post #457
feoren wrote: post #387

Earlier quoted context omitted.

> 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 usel…

> > The naming grew as our understanding of the function grew. > That's exactly it! You have accidentally made my point exactly. No, you just ignored the point I made later about it being contextual. > > 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 kn…

I think we have very different situations in our mind as we go bath and forth like this. It'd be fun to discuss this further over beer, but I think we've mostly hit the limit of what we can do in a HN thread. I'm picking the one major thing you said that I disagree with most:

> Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service.

I just want to stress how tremendously inflexible that is, and just how heavy of a decision you have to make any time you implement a new feature. This sounds like all the negatives of microservices (or DLL hell if that's your deployment model) with none of the positives. Boundaries are fuzzy! I have written a spell checker before. Later I needed an auto-complete service. Turns out: serendipity! I could implement auto-complete easily by simply implementing a separate error model that didn't take off points for "deletion errors" at the end of the word. And as a bonus, it was "fuzzy", so if you typed "Arnold Shwarz" it would suggest Schwarzenegger even though you missed the 'c'. The difference between the Spell Checking Service and the Fuzzy Autocomplete Service was one class of about 10 lines.

If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it really, truly isn't), then you're hamstringing yourself from getting these kinds of easy wins. And maybe you decide autocomplete is close enough to spell-checking to warrant being in the same service, but your colleague might not, so now you needlessly argue over it. It shouldn't be a big decision! Just write it! So auto-complete goes in the service, but it's really close to feature X, which involves vectorizing words, which is the basis for a translation service. Now your spell checker is also a translation service. But what have we really lost? Who gives a crap that Wordsmith now has an extra feature? Nobody who was using its old features; they don't have to change at all.

> > I spent about 30 seconds coming up with "Wordsmith". It does something with words.

> Well, maybe until you're better at it, spend more time.

Needlessly nasty. Maybe I don't want to have a beer with you after all. Come on Wordsmith, I think you're beautiful just the way you are.

Re: Names should be cute, not descriptive

#488

Post by nathan_gold »

In organization chart data, there are people with cute names (John, Jane) and there are positions with descriptive names (Head of Product, Head of Sales).

People's responsibilities change but their cute name does not. But you might not know everyone's cute name, and you want to know who to talk to when something was sold that can't be fulfilled. So you look up Head of Sales in the org chart.

Perhaps having two names is what is needed as in organization charts.

Re: Names should be cute, not descriptive

#489

Post by devnullbrain »

stared wrote: post #310
devnullbrain wrote: post #297

Earlier quoted context omitted.

The mirror to this argument is that company names should also be descriptive. Goodbye Amazon, hello OnlineBookStore.

There is plenty of successful companies with descriptive names. Facebook, IBM, BMW (Bayerische Motoren Werke), Grammarly, Duolingo, OpenAI, etc, etc. Personally, I prefer this approach. When a company gets big, it does not matter. If something is small, at least I get a f---ing clue what it does (and it is easier to memorize).

I'll give you two of those.

Re: Names should be cute, not descriptive

#490

Post by dottedmag »

Scea91 wrote: post #482
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…

Would you extend this to all names and not just product? I attempt to push domain driven design and one of the principles is that a single concept should be called by a single name. It all works well until product management decides to unilaterally push renaming of of concept in UI for vague 'market' reasons...

I do. In my current project there is a rule: if marketing touches it, it's not a name, it's a label.

Starting from the code repository and down to the variables names, only technical identifiers are treated as stable.

Post reply on HN