Earlier quoted context omitted.
> ! NEVER USE CUTE NAMES IN ANYTHING ! So I guess you first-born is called pants-pooper?
No, I address them as child01-mother01, child02-mother01, child03-mother02 and so on.
I like to prepend with year of birth.
Names should be cute, not descriptive
131–140 of 498 posts
Re: Names should be cute, not descriptive
#132Earlier quoted context omitted.
This is because cook books while useful, aren’t entertaining stories. Now if they named it after a good character from a story everyone knows, say the hunter from the big bad wolf, and it’s purpose was to chop up evil wolves taking advantage of grandmas and little girls with baked goods, then everyone knows that character, and as long as the purpose of the service is to defeat impostors trying to do harm then it is f…
;) https://xkcd.com/1053/
How strange! Why wouldn't he just tell her to google it, and go back to looking at his phone?
Re: Names should be cute, not descriptive
#133so are the names master and slave originally meant to be cute or descriptive, and how did that work out for everyone?
Re: Names should be cute, not descriptive
#134As an example of the author's idea in practice, imagine a car, where every part in the car had a cute name, and every car in the world had different cute names. Now imagine being a mechanic. Or going to work for a new car company. Or just being in analytics and trying to understand how to work with the product. Or being a customer trying to understand how your new car works. A part named after its technical role/purp…
The author is not talking about the individual parts though, they are talking about entire services. So basically products or maybe large modules. To use your car analogy: It's the Ford Mustang, not the Ford goes-really-fast-as-long-as-you're-not-taking-any-corners-sporty-car
Read their first two paragraphs again. They're talking about individual services (and so am I). Steeringwheel-svc, Rackandpinion-svc, Shifter-svc, Engine-svc, Transmission-svc, Axle-svc, Tire-svc. Same as filetransfer-frontend-svc, filetransfer-batchloader-svc, filetransfer-batchtransform-svc, filetransfer-db, etc. (those names might still be too generic, but at least you know what I've just described)
Re: Names should be cute, not descriptive
#135I read this article and was surprised it was written yesterday because I could have sworn I read it a few months ago. Turns out I was remembering a post by a different author making the same arguments, discussed on HN here: https://news.ycombinator.com/item?id=32807969
Re: Names should be cute, not descriptive
#136I agree, it would be much better if the article url would be
ntietz.com/puppy/cuddles-and-teddybearsRe: Names should be cute, not descriptive
#137No no no no no. Please never ever do this. From experience, this is thew worst possible decision to make in anything apart from the smallest of organisations (i.e. where production is small enough that all the engineers know (like, really know inside-out and have it all in their head - not just "aware of")), at which point you don't have much to worry about when it comes to renaming something. Please, put yourself in…
As per the article: The problem is that descriptive names don't stay that way. Descriptive names turn into misleading names as the things they refer to change over time. And while code can be refactored, it's very hard to refactor a service name, and almost impossible to refactor it away from people's minds.
Re: Names should be cute, not descriptive
#138Feel like this article was intentionally written to validate Cunningham law and to promote bikeshedding. It's an almost perfect trap for that
Re: Names should be cute, not descriptive
#139Cute 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.
The whole Cloud Native Landscape is full of BS like this: Kong, Skipper, Harbor, Calico, Helm, Linkerd, Flannel, you add the next 50 or so project that I forgotten. It makes the entire thing really complex to navigate, and impossible to talk to others about, because they may have plugged in some network you don't know, but you don't know that it's a network, because the name provides zero clues. Or there might be clues, if English is your native language, otherwise too bad.
It's this needless layer of jargon that doesn't help with the understand of the solution.
Sure, if there's a reasonable chance that your project becomes absolutely massive, then a unique name is a great idea. For internal project, don't be cute, just call the thing by its function. Your warehouse management system should just be "the WMS", not FluffoTron. Should it happen to take on new functionality, then either split that out in a separate project, or just rename the whole thing.
Re: Names should be cute, not descriptive
#140Cute 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.
Kawai Wasabi is incompatible with Yakotori. It is a known choice by the lead developer.
When using Yakotori you should use Tare instead.