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

321–330 of 498 posts

Re: Names should be cute, not descriptive

#321

Post by surement »

grahar64 wrote: post #292
xcambar wrote: post #163

A company I have visited had, for some obscure reason, decided that teams should have their own fun/memorable names. Almost 2 years after implementation, every new hire's first comment was: "it's impossible to navigate the org with those names, we have no idea of what each team is doing". I could live with funny+descriptive, but for all that is good, funny only just does not work.

Yes, and we should change an entire companies culture to make a new hire onboard slightly faster /s

the average tenure for software engineers at most companies is two years, so yes

it's not just onboarding, a newer/more junior engineer is much more likely to misunderstand something and introduce a bug if specific context is required to understand the code

Re: Names should be cute, not descriptive

#322

Post by fckgnad »

ShredKazoo wrote: post #317
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.

Compromise: Come up with a cute name that vaguely suggests what the project does. E.g. instead of "broadcast-service", name it "Cronkite" or "NBC".

Nooo acronyms are horrible. When you have hundreds of services that are acronyms it becomes a nightmare.

Re: Names should be cute, not descriptive

#323

Post by surement »

andy_ppp wrote: post #104

Why not take this to its logical conclusion and name modules, functions and variables cute names too. You need to understand the program and the code could be lying to you with its naming so why bother to name them at all. Start with Pokémon characters, atomic elements, geographical features etc. The possibilities are endless! This naming strategy can also save time when refactoring because you can change the meaning…

just name things with single letters and when you run out you can use double letters etc.

you'll be so fast at writing code a promotion is sure to follow

Re: Names should be cute, not descriptive

#324

Post by themoonisachees »

As a sysadmin who deals with several clients with different naming conventions wrt server hostnames, i feel like both schools annoy me;

for example one of our clients has FRPRTFSQL02, where fr is france, pr is production, tf is the app this server relates to, sql is the type of service this hosts, and 02 is sequential, so for an sql server this means it's most likely a ro replica.

On the other hand, another client names their servers just "montana", "barcelone" or "morroco" with no relation to the geographic aspect of the name.

In both cases, and maybe this is just because i work and exist in this wierd liminal space where i care about the server but not what's on it (if i end up caring what's on it, i find out what i care about by looking at logs etc, not the name) so both ends of the spectrum tell me absolutely nothing about the machine and it's just an annoyance to remember them. I find cute names easier to remember and tell my coworkers about, for what that's worth.

On my own infra, i name my servers with simple descriptive names, like "matrix" is hosting matrix and "play" is hosting game servers, but i don't have the infrastructure for that to be a problem (ie i do not have 2 copies of anything running) so i can afford to do it, but i know it's not a good solution.

Re: Names should be cute, not descriptive

#325

Post by xorcist »

The right question to ask is how and when hostnames are serialized to disk and how you need to interact with them. The most common in my experience are for logging, metrics, backups and monitoring. So those interactions are important use cases to consider.

In my opinion a good hostname, given an enterprise setting and in order of importance, should reflect 1) if the host is production, a staging area, or someone's toy, and 2) which group or team has responsibility or it. If relevant, also 3) what type of server or role it is.

Should you find some sort of data dump or log that contains a hostname, it should be immediately obvious how sensitive it can be and with whom to speak. This basic requirement mostly rules out "cute-only" names.

Re: Names should be cute, not descriptive

#326

Post by twawaaay »

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 is a desired property) but it cannot cause you to think the thing does something it doesn't do.

* It must be unique -- the same name cannot be used for different similar or dissimilar things.

Re: Names should be cute, not descriptive

#327

Post by surement »

AYBABTME wrote: post #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 s…

> I'll tell the PM I need to rename this function if they want to know what I'm up to.

Why can't more engineers do this? in my experience people rarely ever question the product team and you can see this in the products you use all the time. PMs are not robots, they do things the way that seems best given the knowledge they have of the customer and the software, but engineers have more knowledge of the software and they need to communicate it when it's relevant instead of overcomplicating features by blindly shimmying in what product is asking for.

Re: Names should be cute, not descriptive

#328

Post by bmitc »

evandale wrote: post #305
bmitc wrote: post #206

Earlier quoted context omitted.

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?

See https://news.ycombinator.com/item?id=34324480

Re: Names should be cute, not descriptive

#329

Post by rhacker »

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 the package we put it under should be very different from the marketing name - on purpose, so that we don't need to repackage it every 2 weeks. Call it com.companyname.dataintegrator. The marketing name of the data integrator can change all day long and its package must remain dataintegrator.

Re: Names should be cute, not descriptive

#330

Post by thedorkknight »

toomanyrichies wrote: post #253
thedorkknight wrote: post #228

So basically descriptive names might eventually become non-descriptive, or loosely connected. "Cute" names are ALWAYS non-descriptive or loosely connected though. So at worst, a descriptive name eventually becomes as bad as a cutesy name. Given my experience being onboarded onto legacy code, and bringing others up to speed on my team's code, I'd much rather have names help coders understand the systems 9/10 times as…

> descriptive names might eventually become non-descriptive It's worse than being non-descriptive- it's that they become misleading . "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing . This, in turn, means developers can no longer trust that a descriptive name is accurate. It plants a seed of doubt in a developer's mind about other names. It tells them that, here at WidgetCorp…

I suppose. But even though I've definitely dealt with poorly-named microservices in my career, I can't really say as I've come across many that stuck out to me as being especially misleading, and not to the point where it was really an issue
Post reply on HN