Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

11–20 of 498 posts

Re: Names should be cute, not descriptive

#12
Yeah this seems like a terrible argument. Here is what onboarding looks like, if we all followed this:

“Okay so, the part of the app you’re working on is weeble-wobble which handles transactions. Weeble-wobble interfaces with poopy-leg to create financial reports, and with screaming-kidney to do fraud analysis.”

Maybe this is fine for devops? I mean, if pets, not cattle is the regime within the org

Re: Names should be cute, not descriptive

#13

[flagged]

Are you sure you linked to the right thing? https://news.ycombinator.com/item?id=34271510 > Internet socialists / communists / transhumanists seem to infuse their content with a “chibi” vibe, filled with cuteness and hearts. Disagree with them politically, though, and watch out. The sunshine and roses suddenly become bloody slavering fangs.

I’ve never been more sure.

Re: Names should be cute, not descriptive

#17

I've liked "cute" names that are related to their original responsibility in some way. E.g. we had a messaging service called "McFeely" after Mr. McFeely's Speedy Delivery Service from Mr. Roger's Neighborhood. When someone gets onboarded, they'll encounter these names and will have to ask. It's a short anecdote, and it sticks. I'm personally a fan of these, as long as the stretch isn't too far. Themes around names c…

Yeah I nearly posted the same thing. We had a service called "petal" which did settlement - "settle petal" is a bit of Australian slang.

Re: Names should be cute, not descriptive

#18
> 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.

Sounds like there's a workflow problem around renaming services?

Re: Names should be cute, not descriptive

#20
Nice theory. In practice all this does is make it harder to onboard new people. Quick test: It's your 2nd week on the job. Some core system just went down, and you've been assigned to figure out what service is causing the trouble. What makes for easier, more transparent reading of error logs, the name "ServiceRouter", or the name "Trainstation"? It's not just a matter of the name being perfectly descriptive for any and all responsibilities, in zero-context situations it can be good just to give a hint that yes, this is a service, and yes, it at one point handled routing, so it seems like an okay place to start. The more obscure the name, the longer I spend reading about some obscure same-named repository and wondering how it's related to the issue at hand.

That said, I think a certain degree of whimsy is definitely acceptable (necessary?) in the workplace and should be encouraged. I can support silly names for the sake of having fun. But maybe if it's something important, foundational, try to remember it may not be as fun for someone 5 years down the line at 2AM.

Post reply on HN