Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

171–180 of 498 posts

Re: Names should be cute, not descriptive

#171
post #97

The worst is when cute meets descriptive. I've worked at a place where we had dozens of microservices, all named after random mythology. And all names must had some relevance to the actual function of the service. The shopping cart service was named Freyja[0]. The content management service was called Metis[1]. Every single service had a 'cute but descriptive' name, and it was hell. If you didn't know that tale, the…

I still don't get why Freyja would have something to do with a shopping cart?

If I remember correctly it was because she rode on a cart.

Re: Names should be cute, not descriptive

#173
I love this.

Another issue I have with descriptive names is that wrappers and other components quickly get out of hand, then you have machine-learning-worker-wrapper-utils and conversations about this become impossible.

Someone argued that cutesy name hides the responsibility; Personally, I think the effort of resisting making cutesy name do stuff it wasn't originally designed to do is well worth the ease with which you discuss these now concisely named components.

Re: Names should be cute, not descriptive

#175

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.

This. Balance is key imo.

Re: Names should be cute, not descriptive

#177

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…

Solved with company name or product name prefixes, like “discord-routing-service”

Re: Names should be cute, not descriptive

#178
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 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 you'll encounter a descriptive name that lets you actually know what it does and doesn't change over time, the vast majority of the time that name is still hard to write/say and so people use initials which makes the descriptive name pointless.

Use a non-descriptive name, because you can't tell what a service/app does by just the name. People say "google" not "global-web-searcher". You can't tell what a service really does by just the name, so stop trying.

Re: Names should be cute, not descriptive

#179
post #57

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.

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 a "hub", "central repository", "marketplace" or "store"

knife = a command line tool for managing your chef installation

Test Kitchen = a test suite runner

Cookstyle = a code linter

However, now that Chef has gone full Enterprise (never go full Enterprise), the names are now all enterprisey-sounding: everything is "Chef XYZ", e.g. "Buzzword you know + Buzzword you don't", harnesses the CxO's FOMO. Chef Habitat = write declarative rules for applying cookbooks to machines. Chef InSpec = auditing/compliance. Chef Workstation = what you would have normally installed anyway, the development kit and runtime tools, but now it's EnTeRpRiSe, ...

Re: Names should be cute, not descriptive

#180
The more I read about this topic on HN, the more I have a strong opinion that I should not have a strong opinion on this.

(I'm for cute AND descriptive though)

(and somewhat not against anything, unless things too generic like "Web" or "Internet Explorer" for a browser or "File manager" for a file manager)

Post reply on HN