Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

101–110 of 498 posts

Re: Names should be cute, not descriptive

#101
post #91

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.

https://youtube.com/watch?v=y8OnoxKotPQ&t=40 This is how it ends up sounding like.

Came here to post this as well. It's exaggerated but only slightly.

Re: Names should be cute, not descriptive

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

Homebrew is another project that overdoes it IMO

Re: Names should be cute, not descriptive

#103

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.

Even HN frontpage sometimes be "How I use Kawai Wasabi on Yakotori under Sashimi" and there'd be 100 comments, all of them serious. Makes one feel excluded.

Re: Names should be cute, not descriptive

#104
Why not take this to its logical conclusion and name modules, functions and variables cute names too. You need to understand the program and the code could be lying to you with its naming so why bother to name them at all. Start with Pokémon characters, atomic elements, geographical features etc. The possibilities are endless! This naming strategy can also save time when refactoring because you can change the meaning of a variable (for example) without having to rename it everywhere!

Re: Names should be cute, not descriptive

#105

I've found this practice very useful when naming servers, which is an idea I picked up from the Debian project's infrastructure. A physical machine will have a cute hostname, and then the actual service it provides is a CNAME (DNS alias) to it. That way, the physical identity remains steady, but the responsibilities (CNAME) can move around (usually because of upgrade)

I think it's excused if machine fulfills more than one function at once or needs some distinctor among many that fulfil similar function.

If it is a LDAP server in DC1 it should just be "dc1-ldap" or "dc-ldap1" if you have few in redundancy (with actual service being either under "ldap" or "dc-ldap").

But if it is a kitchen sink server running a bunch of services, eh, mjollnir will do, and if you do "ssh ldap" you will ssh to server that hosts LDAP service, regardless of what cute name it will have

Re: Names should be cute, not descriptive

#106
post #49

TFA is based on a false dichotomy. You can have both. At one of my latest workplaces, there was a system of loosely connected, branching event-driven processing nodes where the events accumulated additional data as they rippled through the system. In the code and UI, this was represented as "heroes", coming from "guilds", "embarking" on "quests", eventually meeting their "reaper". On their quests, they entered "locat…

Brew tries this:

You write software formulas (packaging scripts) into bottles (binary packages) in your Cellar (installed packages directory). Some software, such as GUI applications, uses casks, because casks are a different type of container. If you want a new source of packages, you add a tap.

I would take packages, packaging scripts, package repository, binary packages and GUI packages any day over brew's attempt at cutesy terminology.

Re: Names should be cute, not descriptive

#107

Earlier quoted context omitted.

What? You don't want to sift through hundreds of pokemon and anime characters names totally unrelated to the variables and functions of the API you need to use for your job? I'll just write "not a team player" in your annual review.

I'm going through it right now, refactoring https://humungus.tedunangst.com/r/honk honk, zonk, honker, dunk, xonk... the list goes on. This is supposed to be ActivityPub server. Fun. Not.

> reverbolate ... grapevine ... bunchofgrapes

I thought you were kidding, but you're not. Sad.

Re: Names should be cute, not descriptive

#108
It get’a interesting when different companies decide to go down the Greek mythology pathway and the same service names pop up with different meanings in each company :)

Also worth mentioning this as always humorous micrososervice video from Krazam many of you may know already:

https://youtu.be/y8OnoxKotPQ

Re: Names should be cute, not descriptive

#109
I work as a developer at a consulting company, and the consultants are constantly writing new scripts, Excel templates, and so on. Most are early career and get excited about having created something new, so they like using cute names. The practice has been to use a bird name.

So my life consists of bewildering sentences about how raven is old and busted but blue throat will handle this situation, especially if used in concert with agelaius and peregrine, and run on a greyhawk.

TFA is utterly wrong. A few things can perhaps stand the test of time and be worthy of a name, but use cute names sparingly. And, resist the urge to name something at all—it is far better to use umbrella terms inside an organization to avoid mass confusion by those that don’t need to have day-to-day knowledge of your software.

Post reply on HN