Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

51–60 of 498 posts

Re: Names should be cute, not descriptive

#52

Earlier quoted context omitted.

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…

>Yeah but surely there is a directory somewhere that explains this? No, there's 5 different directories in 3 different formats compiled across the last 8 years representing the state of 80% of terms at the time it was last updated, half of which disagree with another version.

I gotta say, I think that's actually just bad technical management, so I suppose it's probably common. Although I will admit Conway's law here.

Nevertheless, the same phenomenon that leads to multiple directories will also mean that supposedly "descriptive" names, will not be.

Re: Names should be cute, not descriptive

#54
post #38

Earlier quoted context omitted.

"policy-engine" is an example of a name that is neither cute nor descriptive

But that's my point. You start writing a new policy engine, and you think the name is obviously descriptive. But in 12 months time, it's not so obvious any more, and also you probably have 3 different policy engines for different use cases.

It should be pretty apparent even from the start that that isn't a descriptive name.

Re: Names should be cute, not descriptive

#55
I made an account on HN because this is the worst post I have ever read here.

NO!!!! DON'T USE CUTE NAMES!!!

I am currently working with a big company for my apps and it is full of cute names which are the biggest problem for me. To launch an app you have first to integrate the Zaamla-Service into your IDE. Then just patch things up with Pimble, upload the signed HIMA-Package into the Katala and activate after that Zanik on the Bremmis platform to include the Mumana-Service to distribute the app.

What? It doesn't work? That's because you didn't integrate the Jonhson-Rod stupid? How is it supposed to work without the Johnson-Rod? Are you even a real programmer?

Re: Names should be cute, not descriptive

#56
This problem is quite interesting from a theoretical point of view.

How to structure a program to be less dependent on its name?

Would it be possible to have a single source of truth for names? So that if you want to change a name, that's a single line commit.

Problem is, if the name is dynamic we'll have to refer to the name using another name.

Re: Names should be cute, not descriptive

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

Re: Names should be cute, not descriptive

#59
If your problem is that names are too descriptive, give your services a number. Because your naming fun will run out of steam, and it'll become cringy as heck when some engineer who thinks (s)he's funny assigns a cute name to a service that makes the rest of the company gag. It's quirkiness for the sake of showing off, not to solve a problem.

Re: Names should be cute, not descriptive

#60
I'll put in a vote in favor of cute names, in the specific scenario of talking (out loud) about specific services - it's less clunky and personally, way easier to correctly parse cute names than common-words-which-may-combine-into-a-service-name.

To take some examples from public cloud:

"We can put that data in Cloud Storage Archive" vs. "We can put that data in Glacier"

"This service runs as a function in Azure Functions" vs. "This service runs as a Lambda function"

"Use the standard machine image" vs. "Use the standard AMI"

On the other hand, I did work on a system where all the services were spaceship names, and that was a nightmare to onboard people onto... echoes of https://www.youtube.com/watch?v=y8OnoxKotPQ , especially as one was named Galactica

Post reply on HN