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

491–498 of 498 posts

Re: Names should be cute, not descriptive

#491

Post by dottedmag »

wruza wrote: post #364
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…

I mostly agree, although from a user side it’s sometimes confusing to encounter random identifiers barely mentioned anywhere.

It requires discipline and good review practices to consistently use either marketing or technical identifiers in any given layer, including UI and API.

Re: Names should be cute, not descriptive

#492

Post by shkkmo »

feoren wrote: post #391
whatshisface wrote: post #381

Earlier quoted context omitted.

The transition was gradual but did happen, and on one side you had a lot of pseudo-religious beliefs and on the other you had experimentation and the scientific method.

And this distinction is important enough to you that you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists", and if they don't, you're going to correct them? Even if it's irrelevant to their main point? That's the discourse we want on here? Everyone had pseudo-religious beliefs back then! Can we not talk about "early astronomers" who were study…

> you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists",

"Alchemist" has a specific meaning, and it is not synonymous with "early chemist". Robert Boyle was clearly an early chemist and predates Isaac Newton, who was an alchemist. There is no temporal hard line in the sand, the distinction is made based on methodology and goals. The two terms aren't necessarily mutual exclusive (as with the astronomy / astrology distinction you allude to), but that doesn't mean you can conflate them.

> Everyone had pseudo-religious beliefs back then!

Perhaps, but that doesn't mean there aren't relevant distinctions to be made about their beliefs and methodologies.

While this distinction is important, it is also irrelevant to my main point. "Vitriol" predates that alchemist and is arguably more of a word that arose than a name that was given.

Re: Names should be cute, not descriptive

#493

Post by shkkmo »

feoren wrote: post #487
kerkeslager wrote: post #457

Earlier quoted context omitted.

> > The naming grew as our understanding of the function grew. > That's exactly it! You have accidentally made my point exactly. No, you just ignored the point I made later about it being contextual. > > Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol. > Yes! That's exactly it! Your CRM program doesn't need to kn…

I think we have very different situations in our mind as we go bath and forth like this. It'd be fun to discuss this further over beer, but I think we've mostly hit the limit of what we can do in a HN thread. I'm picking the one major thing you said that I disagree with most: > Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service.…

> Needlessly nasty. Maybe I don't want to have a beer with you after all

I don't think it was nasty at all. If you'd spent more than 30s on it you'd know that "wordsmith" already means "a skilled writer" and thus doesn't match the function of the tool you are describing. Names that appear to describe the function of a thing but don't are IMHO, the one of the worst kinds of bad names. You're better off with something that is either completely divorced from the underlying functionality or describes it correctly.

Re: Names should be cute, not descriptive

#494

Post by AtlasBarfed »

franga2000 wrote: post #448
AtlasBarfed wrote: post #434

Earlier quoted context omitted.

... that implies all your services already were HTTP-separated or some other swappable network invocation besides direct calls ... Which means... you were microservicing before microservices were a thing? If not, do you care to share how you abstracted your service invocations so they could fluidly go from inter-box comms to separated boxes?

The vast majority of IPC already used sockets decades ago, so it was easy to split a composition of services across multiple machines (just change the config from unix domain- to network sockets). Anything that ran commands to do things could be wrapped in ssh (for example, that's how I offloaded image processing for a sharing site). Two layers of DNS records solve the addressing issue: each box gets a static codenam…

Yeah, CORBA / RMI which microservices eschewed for HTTP.

I had a joke years ago that the reason HTTP services became so popular was simply because those ports were the only ones open in the firewall, so people used those rather than having to get new ports approved by some convoluted security review.

Re: Names should be cute, not descriptive

#495

Post by allenng »

I am so sick of everything having a cute name. Projects can have a cute name; components should not. Imagine if cars did this.

You'd get into your car, and it can have a cute name because it's one name to remember and your car can just be a "Jetta", but the "steering wheel" should be called that. Otherwise you can't go anywhere because you're not sure if you should chauffage the afiafi before you cosmo the thanos.

chauffage: french for "warm" afi afi: samoan for "motor" cosmo: from the Jetson's Cosmo Spacely, maker of sprockets thanos: no logic whatsoever, I just like the movie (and a bit of whimsy is cute, right?) --good luck trying to figure out what it refers to, I'll probably be gone from the company by the time anyone notices

People complain that naming things is hard, but I argue that it's hard if you don't have a good understanding of what the thing is.

Re: Names should be cute, not descriptive

#496

Post by kerkeslager »

feoren wrote: post #487
kerkeslager wrote: post #457

Earlier quoted context omitted.

> > The naming grew as our understanding of the function grew. > That's exactly it! You have accidentally made my point exactly. No, you just ignored the point I made later about it being contextual. > > Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol. > Yes! That's exactly it! Your CRM program doesn't need to kn…

I think we have very different situations in our mind as we go bath and forth like this. It'd be fun to discuss this further over beer, but I think we've mostly hit the limit of what we can do in a HN thread. I'm picking the one major thing you said that I disagree with most: > Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service.…

> If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it really, truly isn't), then you're hamstringing yourself from getting these kinds of easy wins.

It's not "immediately setting out with a mindset", it's looking back on coming-up-on-2-decades of software development experience and noting that every time I think bolting a second responsibility onto a unit is an easy win, that decision comes back to bite me. It seems like an easy win now, but everything you change in that area of the code from now on needs to consider two different, disparate responsibilities it needs to maintain.

If you're seeing this as an easy win, it's likely that your software didn't see much use that played out the problems, or you didn't stick around long enough to see the problems arise, or someone else did the work to fix it and just didn't tell you.

> Nobody who was using its old features; they don't have to change at all.

Not yet, but if you assume they'll never have to change, you're going to have a bad time.

What's the longest you've ever worked on a codebase? Have you ever been the sole developer on a large codebase, where you had to pay for your own mistakes?

Re: Names should be cute, not descriptive

#497

Post by bobbiechen »

pbnsh wrote: post #73
bobbiechen wrote: post #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 Func…

Was that company by any chance founded by a rick roll sent via an api/sms and has 4 dots in it's logo?

Yeah, it's Twilio - my profile here is easily connected to my work history haha.

Re: Names should be cute, not descriptive

#498

Post by xtiansimon »

xtiansimon wrote: post #182

Funny trifle. I too like cute names at high levels of abstraction, because descriptions or explanations shouldn’t clash with the named bits—particularly in documentation. But when a named thing doesn’t escape the code files, then it has to be descriptive. My projects take too long, and coming back to a too cute name is a PITA. The exception is I use verb+cute name for command line script names. Naming is hard, but al…

Curiously, this week I was doing some project in Python where a visual plot was necessary. Now here’s a sphere where naming actually sux. I say this because there is a rich history of terms around visuals. When your project includes these other ontologies, it’s not so fun.
Post reply on HN