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

311–320 of 498 posts

Re: Names should be cute, not descriptive

#311

Post by xorcist »

doctor_eval wrote: post #25
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.

Yeah but surely there is a directory somewhere that explains this? I mean - the problem is not the number of names but the number of services. A new hire still isn't going to be able to work out what a service does just based on the name, regardless of how whimsical or apt it is. "policy-engine" might seem to be a good name for a service, but it's only one level below "kevin" in terms of opaqueness, especially when t…

A directory does wonders. Make it hierarchical too. That way different zones can have different values.

It can point "policy-engine" to which host runs it. Or, even better, make it resolve the IP address directly!

Re: Names should be cute, not descriptive

#312

Post by gloosx »

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 feel you here, amount of non-descriptive stuff inside cold imperative spaghetti is now really impressive across companies, I can't really call something like this a system but a nailed coffin for the business. Only with solid experience comes the knowledge that you need to express you mind-train as simple as possible to understand from first glance and your migraines will go away

Re: Names should be cute, not descriptive

#314

Post by sesteel »

jxf wrote: post #303

> 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…

Could not agree more. Naming things for what they do encourages other behaviors like deprecation strategies and extension strategies that are non-disruptive to others. It makes people's lives easier if your work follows a level of rigor for naming. Products and companies can do many things under a single name, APIs should try to do the fewest number of things under a given name while fitting the concept as closely as possible.

Re: Names should be cute, not descriptive

#315

Post by xorcist »

amiga386 wrote: post #179
jnsaff2 wrote: post #57

Earlier quoted context omitted.

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.

Absolutely this! In case anyone isn't aware of the insane thematic naming in Chef: Chef = a configuration management tool Recipe = an individual Ruby script that makes sure something is installed and configured correctly (e.g. a mysql recipe) Cookbook = a bundle of recipe(s) and basic metadata (what do these recipes do, who wrote them, etc.) Supermarket = a community site with common cookbooks, what others would call…

Puppet went full enterprise too and now there's a dizzying amount of "products" catering to your needs.

It's written on the wall for Ansible, Red Hat/IBM is busy churning out the product space already.

It's weird that there's so much money in enterprise IT. If anything, they should know the value of standards and reference implementations.

Almost 25 years ago, SSH went full enterprise and promptly died. Somehow the need for a simple remote shell protocol didn't, though, and now OpenSSH is instead perhaps the most valuable tool we have.

Re: Names should be cute, not descriptive

#316

Post by surement »

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…

> It's worse than being non-descriptive- it's that they become misleading.

if you find that something has drifted to the point of being misleading, then rename it

it's software not hardware

or comment on code reviews that change the functionality to the point where this is a problem

Re: Names should be cute, not descriptive

#317

Post by ShredKazoo »

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".
Post reply on HN