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

331–340 of 498 posts

Re: Names should be cute, not descriptive

#331

Post by AlanSE »

This reminds me (from a long time ago) of seeing IT department stick names of jungle animals on computers so they can be recognized on the network.

These days, there are many cases where _instances_ of something are given random "cute" names. A particular server will have a suitable-for-work but fun name slapped on, like "grumpy goat".

Hover, I can't imagine _classes_ of something following that kind of naming convention. This post seems to be more about _queue_ names or _service_ names. Software DOES intentionally use cute and random names for big-ticket items (see "git"). It would be confusing to apply this practice to more minor software, because it would be too many to remember.

If I have a service as a part of an app that consumes data from a redis queue and sends it to a log collector, a fully descriptive name is distasteful, but I wouldn't want to name it "anteater" because even if my mental picture is vivid, other people will... not get it. I'd call it "log-passer" or something.

Re: Names should be cute, not descriptive

#332

Post by surement »

btbuildem wrote: post #193

This is one of the hardest problems in software development, and with good reason. Naming things is how we get a handle on them, how we mark our understanding of them. It's a pivotal issue, in how it attaches our brain-maps to the problems we tackle. How many times, as a developer, have you paused and pondered what to name a new entity? I often find the difficulty of naming a thing is directly proportional to my dept…

> This is one of the hardest problems in software development

and that is one of the worst fallacies in software development

naming things is not hard, people regularly give things terrible abstract names because they act like it'll never be possible to rename it and then add a 3-4 word comment above describing what it does

if they just named it what the comment says then they'd have a fine name

Re: Names should be cute, not descriptive

#333

Post by kevincox »

twawaaay wrote: post #326

I think names should first of all be reliable . What I mean by reliable? * It does not change either in time or space -- you have to come up with a good name right from the start and then you are not allowed to change it. The same thing has to be named the same way throughout the system and ideally through multiple connected systems. * It must not mislead -- the name does not have to be super descriptive (although it…

Your list is very similar to mine: https://kevincox.ca/2021/03/23/good-names/

I agree. The uniqueness and stability of a name is key. Then making is not mislead is good. Then being descriptive is nice.

I think the article is hitting on descriptive names can become misleading over time. People will think that a descriptive name is helpful, even if it was poorly chosen or is no longer accurate.

Re: Names should be cute, not descriptive

#334

Post by bmitc »

ImPleadThe5th wrote: post #254
bmitc wrote: 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…

I think there is a happy medium. I think you can have a cutsey name that gently suggests what the service is responsible for. I don't fully know what task-service does, I don't know how it differs from scheduled-task-service-v2 . In the same way I don't know what starship does or how its different from rocketship . But I can probably guess and easily remember what 'automated-task-scheduler' or 'The Taskinator' does.…

I agree with there’s a middle ground, especially depending on what level you are in the stack. However, I would consider those examples you gave to be descriptive and certainly not overly cutesy or fun.

Re: Names should be cute, not descriptive

#335

Post by surement »

__MatrixMan__ wrote: post #283

I agree with this. Where I work, one team has given descriptive names to everything and several other teams have then shortened them inconsistently. So it's tribal knowledge that "cloud" and "gen2" are the same thing, and software/platform/gen1 are almost the same thing, but configured differently. If we had called them Frank and Susan, we'd know what each other means.

if your solution to overly generic names is names that are meaningless without context, you probably have bigger problems

Re: Names should be cute, not descriptive

#336

Post by kevincox »

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 where a "codename" is a much better match. Having two names is generally only a tiny bit confusing.

I have also yet to see a codebase rename that completes before the product name changes again. You always just end up with a confusing slew of N names in the codebase if you try to rename.

Re: Names should be cute, not descriptive

#338

Post by Spivak »

71bw wrote: post #277
Spivak wrote: post #248

Earlier quoted context omitted.

Another example is Discord. In the beginning Discord servers were called Guilds and that's still their name in all their documentation and APIs. So it's more than company names.

Discord is a... indecent woman to work with, if you want to build a bot once so that it works for any longer period of time... you need to wake up, because that's sadly not how it works.

I have no idea what you're talking about but Discord has got to be one of the most pleasant bot development experiences that exists. Their shit is really well architected and their API handles so much lifting for you.

I get that some people were burned by the switch from "free-for-all text bots" to structured bots with OAuth but the new way is so so so much better.

Re: Names should be cute, not descriptive

#340

Post by discordianfish »

(Micro)service names should be descriptive and stick to doing what they are named after. If you need to change the scope, it's an change to the overall architecture and changing the name and good way to communicate that. If a employee reads the name they know what its suppose to do.

Company and product names (including e.g open source projects) are different. You want to be able to change your scope depending on customer demand without having to rebrand.

Post reply on HN