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

351–360 of 498 posts

Re: Names should be cute, not descriptive

#351

Post by toomanyrichies »

salawat wrote: post #286
toomanyrichies wrote: post #253

Earlier quoted context omitted.

> 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. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing. My God... You don't mean to tell me you actually object to having to read code and figuring out what it does in the grand scheme of things? I swear, everyone wants to be a writer, but no one wants to read and understand.

Not only is your comment needlessly snarky, but it also mis-characterizes what I said. Show me where in my comment I said that I "object to reading code and figuring out what it does in the grand scheme of things".

What I "object to" is not being able to trust that a class or method does what it says on the tin. I don't think that's unreasonable. I'm fine with reading code in order to understand how something works. I don't want to have to read code in order to verify that it does what it promises. See the difference?

Re: Names should be cute, not descriptive

#352

Post by mook »

JackFr wrote: post #285
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.

You can have the worst of both worlds. I've worked at three(!) seperate companies which have had projects called 'Hydra' (and the number of people who were ignorant of what the Hydra was, and why it might not have been a great name for a software project never ceased to amaze me.) I like clever, cute names. That is names like Hydra, Spirit, and others which are unrelated to the function, but which are anodyne and gen…

I worked at a startup with a bird theme for a bit under 4 years. There were three separate things named Nightingale in that time. By the time I left, it was kind of a joke to suggest that as the name for random things.

Re: Names should be cute, not descriptive

#353

Post by ghostpepper »

leeches wrote: post #177
fiddlerwoaroof wrote: post #75

Earlier quoted context omitted.

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”

except nobody at discord would ever call it "discord routing service" in a conversation with other discord employees

Re: Names should be cute, not descriptive

#354

Post by tauwauwau »

leokennis wrote: post #281
tauwauwau wrote: post #200

I think we are mixing two different scopes in the the discussion here. If you are naming a company or a product that will be offered to clients, name it something unique that'll appear in searches. However, if you're writing a piece of software that's not going to go outside the company, having descriptive name is the way to go. You can even name your products with generic descriptive names, if your company's name is…

The issue is, if you create an internal tool that allows you to order printer paper for your departments printer you might name it "PaperSupplier": https://papersupplier.acme.com . If it doesn't work, just send a mail to papersupplier@acme.com! And it works so well, the company now also wants employees to order staples and hole punchers through it. What do you do now? Are you going to rename the tool, change the addr…

You are right that function may evolve over time and name may not be completely accurate but it's still partially accurate opposed to being being completely inaccurate. In your example papersupplier, I would want to create a new site for staples or better create a new site for all categories of stationary instead of modifying the old one.

I like the idea of having a generic but still descriptive name.

Re: Names should be cute, not descriptive

#355

Post by feoren »

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.

> Cute names are a nightmare when a company has accumulated hundreds of quirkily named things that you have to memorize

Now imagine trying to navigate hundreds of things that are descriptively named wrong. The argument isn't between (A) cutesy names, and (B) accurate descriptive names. B is obviously better. But that's a fantasy world that doesn't exist. The argument is between A and (C) descriptive names that rot over time (quickly or slowly), which is actual reality.

Re: Names should be cute, not descriptive

#356

Post by ghostpepper »

xorcist wrote: post #315
amiga386 wrote: post #179

Earlier quoted context omitted.

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

I had no idea there was ever a company called SSH but apparently they still exist . Seems they were way ahead of the curve on what became known as "open core"

Re: Names should be cute, not descriptive

#357

Post by nix0n »

erikpukinskis wrote: post #348

There’s some history here people are missing. Back in the day we used cutesy names for boxes , and we did it for good reason: Back then, before cloud services, when you were building out an application, you would build one computer, load it up with some services, and then when that one started performing poorly you’d add another computer and move some of the services off. You would frequently rebalance which services…

I agree that this makes sense for boxes.

> we named them Athena, Zeus, etc

The bonus of this kind of theming is that if someone mentions a Greek god you know they probably mean a box.

One reason this makes more sense for boxes, is that a box will have features and responsibilities taken away more than a program or service will.

If a service is named according to what it originally did, even though it took on additional responsibilities, that's fine.

Re: Names should be cute, not descriptive

#358

Post by pphysch »

kevincox wrote: post #336
rhacker wrote: post #329

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…

100%. I was at a company and they kept renaming the internal name to match the marketing name. We had 3 names for some older tech and 2 names for the less than a year old service. I strongly recommended that we should adopt the original name as a "codename" and use it for code and internal technical documents. Marketing should absolutely have full control over the user visible name. But technology has different needs…

It seems that most business objects should have all of the following:

1) A memory-friendly, indexed, unique, immutable ID (e.g. BIGINT or GUID).

2) A human-friendly unique immutable codename/slug.

3) A human-friendly mutable marketing/display name.

1 & 2 could be combined in some cases

Re: Names should be cute, not descriptive

#359

Post by trynewideas »

There's a decent middle ground where the cute name is also descriptive, even if it's indirectly so.

For instance, Grafana's stack is

Logs

Graphs

Tracing

Metrics

so their services are

Loki

Grafana

Tempo

Mimir

which also spells "LGTM".

Of course, then they shipped "Phlare" because apparently they couldn't find a cute name for Profiling?

Re: Names should be cute, not descriptive

#360

Post by liotier »

seniortaco wrote: post #346
moehm wrote: post #152

Earlier quoted context omitted.

Is Tare even maintained? I tried to build it with Mochi, but it gives weird error messages.

Why would anyone still build it manually? Tokidoki automates all of that, and all you have to do configure your .toki bundles after you've installed the right SpaghettiWare layer for your architecture and connect it with either Tutti or Frutti. Easy peasy lemon squeezy! Oh that reminds me you do need Squeezy running in the background.

Uh ? Aren't your .toki bundles autogenerated from picks in the CherryOrchard directory ? Don't touch them - let the NoodleBlossom pipeline trellis abstract that for you !
Post reply on HN