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

461–470 of 498 posts

Re: Names should be cute, not descriptive

#461

Post by layer8 »

banku_brougham wrote: post #431
wvenable wrote: post #395

Earlier quoted context omitted.

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…

To me the most painful style of wasted effort is that of renaming an entity and all of the connection points to other services, and documentation, wikis, slack channel names, email lists, etc. because the name is causing cognitive dissonance.

I guess it can be subjective whether the cognitive dissonance isn’t more painful, but it certainly can be a constant strain. This is especially the case if the term in question is a software engineering term you also want to use in its regular meaning. “Cute” names at least avoid that situation.

Re: Names should be cute, not descriptive

#462

Post by deltarholamda »

tremon wrote: post #301
deltarholamda wrote: post #241

Earlier quoted context omitted.

I've heard the "cattle not pets" argument for servers, but I hate that. Naming a server is like naming a boat. I've done it where everything is named after astronomers, or physicists, or even comic strip characters, but I also like it when a server is named, well, with a name. "Hey guys, Jeff is throwing errors again, need somebody to find out what Jeff's problem is."

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

Re: Names should be cute, not descriptive

#463

Post by layer8 »

zffr wrote: post #422
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.

Are they easy to change? Consider the scenario of a SDK provided to external developers (ex: UIKit). Any symbols made to be public API cannot be changed between releases cannot be changed without breaking clients. It's true the SDK authors can deprecate and remove symbols, but this is not always easy to do, and sometimes can take several months or years to do.

Public API names aren’t easy to change, for backwards compatibility reasons, but for the same reason you also wouldn’t change their semantics, which is what would trigger a rename.

The exception is when a name is wrong for the semantics from the beginning. In that case, there’s usually the option to deprecate it (make it trigger a warning) and only keep it for compatibility, and add the correct name as an alias next to it.

Re: Names should be cute, not descriptive

#464

Post by layer8 »

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.

You can expose multiple things with each having their own name, and still have it implemented within a single service (single unit of deployment). The clients however don’t have to depend on it being a single service; it can appear as separate services to them. That way the scope of the “all in one” service name remains limited, and can therefore also be more easily changed.

This is similar to running multiple services on the same host, but clients don’t use the canonical hostname, but service-specific subdomain names.

Re: Names should be cute, not descriptive

#465

Post by wlonkly »

I worked at a place that did the typical geek naming thing, with the Greek and Roman pantheon. They were cleverly chosen, so that you could remember that "mercury" was the messenger, and so on. But still, you couldn't tell anything from a name unless you already knew the connection.

So we went with serious names: Message Sending Service, User Account Service, and so on. And the result is that every service has a valueless "Service" appended to it and everyone just throws acronyms around now. So you can't tell anything from a name unless you already know the acronym.

Overall I think the answer is that things that involve a lot of interaction can have creative names, and things that are rarely interacted with have to have more meaningful names. Call the monolith "Princess Unicorn". Everyone will end up knowing what Princess Unicorn is through proximity. But call the annual billing reconciliation process "Annual Billing Reconciliation".

Re: Names should be cute, not descriptive

#466

Post by wlonkly »

DaedPsyker wrote: post #147
eps wrote: post #103

Earlier quoted context omitted.

Even HN frontpage sometimes be "How I use Kawai Wasabi on Yakotori under Sashimi" and there'd be 100 comments, all of them serious. Makes one feel excluded.

Tech naming has become a pet peeve of mine. Too many common nouns are being used. Something like coffeescript is at least distinct but then you get a hundred things that will be called something like apple juice, based on some in-joke connected to a stack that will be called orchard.

Don't even start me on the Chef ecosystem.

Re: Names should be cute, not descriptive

#467

Post by wlonkly »

mrweasel wrote: post #139
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.

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.

Re: Names should be cute, not descriptive

#468

Post by wlonkly »

ilyt wrote: post #98
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.

You need to do it anyway if your names are too descriptive* "video-encoder is not working" "oh, you mean ffmpeg" "no, our microservice is called video encoder" Also they are not neccesarily one or the other, you can name something that hints at its function but it is not straight dictionary description of it.

Should've called it "video encoder service". Then people could refer to VES and you'd still have no idea what it was.

Re: Names should be cute, not descriptive

#469

Post by fsckboy »

this is one of the designed benefits of hungarian notation, generating short, unique (not already overloaded) names that give a notion of type or class, and a distinguishing descriptor/mnemonic.

these terms can take on a memorable cuteness factor without being a sledgehammer of cuteness that crushes any notion of meaning.

Re: Names should be cute, not descriptive

#470

Post by wlonkly »

jnsaff2 wrote: post #57
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.

One of the cute names horrowshow for me is Chef. Everything is based on some supposedly cooking analogue that just does not fit with (at least my) mental model of IaC.

I worked at a place where people would write their own wrappers for Chef things, name them, and then refer to them by that name. "Dave, nobody has any idea what 'spork' is."
Post reply on HN