Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

141–150 of 498 posts

Re: Names should be cute, not descriptive

#141
For broad services and product lines, this is 100% correct.

Change is inevitable and having a simple (cute) name allows collective semantics to float with reality as it changes.

Of course for less volatile components, descriptive is useful, almost necessary.

One of the most important skill sets in putting together technical systems is understanding the difference between volatile vs stable components.

The problem I’ve found is that so many technical people can’t fathom change or see where change is inevitable. So they operate as if everything is stable.

That’s why you see so much pushback against the idea proposed here.

Re: Names should be cute, not descriptive

#142
post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

> > Trouble is, names are hard to change.

> No they’re not. People just aren’t determined or organized.

I think this point from the article gets to the harder part.

> Once you've said a name, it starts to stick in people's heads, and it slips beyond your control. Other people use the name in conversation and it ripples out through the organization.

Technical modifications to change a name are one thing. Once people are stuck with using a particular name, it can be hard to change that.

Re: Names should be cute, not descriptive

#143

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.

I have the opposite problem as a recent new hire: when "cute" project names show up in a conversation, it signals something company-specific I need to learn about. When descriptive project names are used (especially if the projects are using really generic one or two word names like "routing-service"), it is harder to realize that people are talking about an implementation of a concept rather than a well-known concep…

This is basically by fast the best argument to use cute names over some main components, and by "main" I mean when there are few of them, less than a dozen or so.

An old name made of well-known technical words can easily suggest a level of complexity much smaller than what it has evolved into and therefore developers -specially new devs- should look it up instead of assuming what it does based on potentially misleading namings.

Re: Names should be cute, not descriptive

#144
post #44

I wouldn't necessarily call them cute, but "Odin" (my phone), "Tyr" (my NAS) and "Thor" (my home server) would surely agree.

Cute names don't scale. You can name your servers after star trek characters, and routers after star wars characters, only if you have very few.

Sure, yes - something that's not an issue at my home, but surely will at other places.

Regarding naming - Middle Earth should have many possible names at hand.

Re: Names should be cute, not descriptive

#146
post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

> You know what is fun when it comes to work? Things that work, are named appropriately, are understandable, and people not needing trivialities

I don’t know I agree with this. Microsoft has taken the descriptive naming style all the way down to products. Not only names like Batch or Functions don’t add much value, but also it makes searching information about them much harder than “cute” names (such as Excel).

I also think we tend to overthink this too much. In the end, the significance of names is as high as choosing between tabs or spaces.

Re: Names should be cute, not descriptive

#147
post #103

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.

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.

Re: Names should be cute, not descriptive

#148
How about making them descriptively memorable:

    - shifting-priorities-routing-service
    - indiscrete-secrets-vault
    - gdrp-user-immolator
    - knock-knock-whos-this-authn
    - canihaz-authz
I don't buy the "can't rename services" arguments though. It's also hard to rename variables, modules and stuff. We do it. I'll tell the PM I need to rename this function if they want to know what I'm up to. How often does a service morph so much that it needs to fundamentally change its vaguely-descriptive-name? Realistically I don't think I've even seen this happen once.

Re: Names should be cute, not descriptive

#149
post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

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.

Re: Names should be cute, not descriptive

#150
post #126
post #64

Earlier quoted context omitted.

I say, go for both. Go all Boaty McBoatface on that thing. Boaty McBoatface is silly, but it is unarguably a memorable name for a boat. There are other, less silly, but equally memorable (and maybe even cute) descriptives out there. On a different note: if you are presented with an either/or choice, your first instinct should always be to ask if they are actually opposites or if you can also have both if clever.

> memorable name is it ever a problem in software engineering, that you can't remember what that component's name is? I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name, and maybe they don't do SEO well on package repositories (why would they, software engineers). So, when I look npm up for that problem, th…

> is it ever a problem in software engineering, that you can't remember what that component's name is?

Yes. When the names are descriptive or bland, it's almost impossible to remember what it is.

Post reply on HN