The worst is when cute meets descriptive. I've worked at a place where we had dozens of microservices, all named after random mythology. And all names must had some relevance to the actual function of the service. The shopping cart service was named Freyja[0]. The content management service was called Metis[1]. Every single service had a 'cute but descriptive' name, and it was hell. If you didn't know that tale, the…
I still don't get why Freyja would have something to do with a shopping cart?
Names should be cute, not descriptive
171–180 of 498 posts
Re: Names should be cute, not descriptive
#172Re: Names should be cute, not descriptive
#173Another issue I have with descriptive names is that wrappers and other components quickly get out of hand, then you have machine-learning-worker-wrapper-utils and conversations about this become impossible.
Someone argued that cutesy name hides the responsibility; Personally, I think the effort of resisting making cutesy name do stuff it wasn't originally designed to do is well worth the ease with which you discuss these now concisely named components.
Re: Names should be cute, not descriptive
#174Re: Names should be cute, not descriptive
#175A company I have visited had, for some obscure reason, decided that teams should have their own fun/memorable names. Almost 2 years after implementation, every new hire's first comment was: "it's impossible to navigate the org with those names, we have no idea of what each team is doing". I could live with funny+descriptive, but for all that is good, funny only just does not work.
Re: Names should be cute, not descriptive
#176Re: Names should be cute, not descriptive
#177Cute 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.
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…
Re: Names should be cute, not descriptive
#178I 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…
Use a non-descriptive name, because you can't tell what a service/app does by just the name. People say "google" not "global-web-searcher". You can't tell what a service really does by just the name, so stop trying.
Re: Names should be cute, not descriptive
#179Cute 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.
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 a "hub", "central repository", "marketplace" or "store"
knife = a command line tool for managing your chef installation
Test Kitchen = a test suite runner
Cookstyle = a code linter
However, now that Chef has gone full Enterprise (never go full Enterprise), the names are now all enterprisey-sounding: everything is "Chef XYZ", e.g. "Buzzword you know + Buzzword you don't", harnesses the CxO's FOMO. Chef Habitat = write declarative rules for applying cookbooks to machines. Chef InSpec = auditing/compliance. Chef Workstation = what you would have normally installed anyway, the development kit and runtime tools, but now it's EnTeRpRiSe, ...
Re: Names should be cute, not descriptive
#180(I'm for cute AND descriptive though)
(and somewhat not against anything, unless things too generic like "Web" or "Internet Explorer" for a browser or "File manager" for a file manager)