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

221–230 of 498 posts

Re: Names should be cute, not descriptive

#221

Post by sixstringtheory »

The renaming point is actually the great point in this article IMO. But this just tells me that languages, platforms, frameworks and editors need to improve so that renaming things is easier. Or that people need to learn how to use grep/sed better (ETA: and use monorepos)…

But this:

> they're no fun

> it won't be fun

is the bane of my existence as someone who tries to get shit done. If this is the lens through which you view software development, and I have to work with you at my job, I literally hate you.

Re: Names should be cute, not descriptive

#223

Post by kzrdude »

doctor_eval wrote: post #25
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.

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…

Directories somewhere that pedagoically explain all the codenames, nah that doesn't necessarily exist in the company until it grows larger. It might just be a quagmire for new hires in a growing company.

Re: Names should be cute, not descriptive

#224

Post by formerly_proven »

pmelendez wrote: post #146
bmitc wrote: 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…

> You know what is fun when it comes to work? Things that work, are named appropriately, are understandable, and people not needing trivialities I don’t know I agree with this. Microsoft has taken the descriptive naming style all the way down to products. Not only names like Batch or Functions don’t add much value, but also it makes searching information about them much harder than “cute” names (such as Excel). I als…

This really seems to have started at Apple and has been copied by both Microsoft and Gnome. I don't have any UX expectations for MS [1], but in Gnome it's irritating because most Gnome applications don't display their real name anywhere in the UI any more, so you have to Google what the binary and package names are etc.

[1] I tried to open calculator on a Windows 10 box and it doesn't work any more, even launching calc.exe directly just gives a weird error message that "I need a new app for opening this ms-calculator:// link". Wat.

Re: Names should be cute, not descriptive

#225

Post by dclowd9901 »

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.

As an Amazon developer, I feel this. No wonder it’s so hard to get shit done.

Re: Names should be cute, not descriptive

#226

Post by bmitc »

lodovic wrote: post #201
bmitc wrote: post #191

Earlier quoted context omitted.

We're talking about software service and component names. Not names in general or company names.

In a large enough project, this sometimes results in pull requests covering hundreds of files. While the renaming itself may be a simple task, getting multiple reviews takes a lot of effort and management may have other priorities.

I have renamed a large-ish service that was integral to the whole system before. For one, it wasn't that hard. And secondly, it usually reveals some existing issues and architectural deficiencies.

Re: Names should be cute, not descriptive

#227

Post by perrygeo »

bmitc wrote: 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…

> you can work there for months before you know what does. It’s because it’s generic and because a “fun” name was chosen, its responsibilities have not only changed but its number of responsibilities have changed

Excellent insight! If you use cutesy names, the intent of the component will get muddled and responsibilities will be strewn about. I've never seen an exception. Your components become a fuzzy set of containers into which all ideas are tossed without any design intent.

The only way I've seen to avoid this is to develop your own taxonomy/dictionary defining what all the cutesy names mean, what their interfaces/boundaries should be, etc. At that point, consider how much time you've wasted building and training your team on a bespoke vocabulary ... why not just encode the meaning into the name itself? Precise naming leads to better design and most importantly, encourages future developers to actually following that design.

Re: Names should be cute, not descriptive

#228

Post by thedorkknight »

So basically descriptive names might eventually become non-descriptive, or loosely connected. "Cute" names are ALWAYS non-descriptive or loosely connected though. So at worst, a descriptive name eventually becomes as bad as a cutesy name.

Given my experience being onboarded onto legacy code, and bringing others up to speed on my team's code, I'd much rather have names help coders understand the systems 9/10 times as opposed to 0/10 times

I'm not sure I see the point

Re: Names should be cute, not descriptive

#229

Post by stiiv »

> The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.

This analogy falls short. Services aren't like people -- their names aren't bound to their origination, but they can be bound to their function. That's a choice for a developer to make.

But how common are are actual mismatches between service responsibilities and names, really?

What kinds of systems or features or teams do name/function mismatches commonly track?

Speaking strictly for myself: I've worked on SOAs and microservices (mostly for .NET) since 2005 for half a dozen companies on both new and existing systems, and I can't recall _any_ such mismatches.

Re: Names should be cute, not descriptive

#230

Post by nightowl_games »

I agree. Right now I'm working on a service called simply 'backend'. We are adding some environment variables to it, and I'd like to prefix them with something relatively unique. BACKEND_DATABASE_ADDRESS is simply not unique enough to pollute the environment with. I know this example isnt perfect (and no were not even writing these env variables to the user's shell), but it demonstrates the lack of identity.
Post reply on HN