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

301–310 of 498 posts

Re: Names should be cute, not descriptive

#301

Post by tremon »

deltarholamda wrote: post #241
beefield wrote: post #110

Well, I have worked in an environment where database server names were server software version concatenated with a shortish but high entropy random alphanumeric string. I'll take cute or descriptive any day over that.

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.

Re: Names should be cute, not descriptive

#302

Post by [deleted] »

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…

[deleted]

Re: Names should be cute, not descriptive

#303

Post by jxf »

> I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name.

I couldn't disagree more. This is exactly why you would want the name to be descriptive. If the thing that's supposed to be a notifications service suddenly also starts processing payroll, that's absolutely a friction point that should give people pause.

Re: Names should be cute, not descriptive

#304

Post by bumby »

DoughnutHole wrote: post #252
MrGilbert wrote: post #233

Earlier quoted context omitted.

But isn't that exactly the "work around it" part? There are full standards one needs to adhere to, so you basically work around the sloppy part of human nature.

Exactly - engineers don't change their nature, they're legally mandated to follow very strict rules regarding best practices. They work in heavily constrained systems with checks and balances to prevent slip-ups. If they don't follow the rules and something goes wrong they're legally liable. Strip away the systems that coerce engineers into complying with best practices and you'll very quickly see how little their "n…

Software development seems much more opposed to standardization than traditional engineering disciplines. I don't know if it's an artifact of software development itself (e.g., things are just so easy to change by comparison that it becomes hard to set a standard because things move so fast) or if its an artifact of software being a much newer discipline than others. E.g., when you look at mechanical designs from the early industrial age, it becomes pretty clear there were no standards then either.

Re: Names should be cute, not descriptive

#305

Post by evandale »

bmitc wrote: post #206
gilbetron wrote: post #178

Earlier quoted context omitted.

I utterly disagree with you. After 30+ years of doing this, I almost always despise "descriptive names" - they are almost always wrong, generic, and hard to say/type. They are difficult to change, and even if you do change them, you just end up with another crappy descriptive name. "database-writer" or "user-database-writer" or "database-post-writer" or "event-logger" or "event-logger-2". While every once in a while…

Descriptive names can still be bad. Cute names have no chance of being useful. Someone else pointed it out or alluded to it, but I suppose there is a gradient of abstraction. The level of abstraction, from product to service to component to module to function to variable names, probably determines some allowance in how generic the name can be, from more generic to less generic, respectively.

> Cute names have no chance of being useful

Are the names Amazon, Google, Facebook, Kleenex, Q-Tip, Thermos, Yo-Yo, or Zipper useful? They're all cute names and I'm positive most people could tell you what each of these things do. How is that not useful?

Re: Names should be cute, not descriptive

#306

Post by foxyv »

I usually do both. I'll have an easy to remember Code name followed by a descriptive name. This is to disambiguate the 700th TranslatingProxyLayer project. For example: ReliantRobin-DatabaseCleaner

Now when I search for it in a wiki or documentation I can find it easily, but people still know what the heck it is.

Re: Names should be cute, not descriptive

#307

Post by nivenkos »

JackFr wrote: post #285
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 can have the worst of both worlds. I've worked at three(!) seperate companies which have had projects called 'Hydra' (and the number of people who were ignorant of what the Hydra was, and why it might not have been a great name for a software project never ceased to amaze me.) I like clever, cute names. That is names like Hydra, Spirit, and others which are unrelated to the function, but which are anodyne and gen…

It feels like every company has an Apollo, Hydra or Hermes...

Re: Names should be cute, not descriptive

#308

Post by rhacker »

> Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.

But that's just your perspective. At HogCorp Sam is the Senior Data Engineer. People that need data adjustments probably go to the Senior Data Engineer, whether that is Sam or not. If Sam becomes VP of Accounts and is no longer the Senior Data Engineer, people won't stop going to the Senior Data Engineer, but it won't be Sam anymore.

Re: Names should be cute, not descriptive

#309

Post by surement »

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.

> "no, our microservice is called video encoder"

using cute names shouldn't be an alternative to learning to name things properly

Re: Names should be cute, not descriptive

#310

Post by stared »

devnullbrain wrote: post #297
stared wrote: post #293

Let's go further: Function (and class) names should be cute, not descriptive. It is impossible to predict how these evolve and change their names.

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

Post reply on HN