61–70 of 498 posts
Earlier quoted context omitted.
But that's my point. You start writing a new policy engine, and you think the name is obviously descriptive. But in 12 months time, it's not so obvious any more, and also you probably have 3 different policy engines for different use cases.
It should be pretty apparent even from the start that that isn't a descriptive name.
If your service starts taking on responsibilities that render the name non-descriptive, then it's likely taking on responsibilities that it shouldn't, and you need to have a talk with your architect, same as you would with an entirely local app.
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.
There are other, less silly, but equally memorable (and maybe even cute) descriptives out there.
On a different note: if you are presented with an either/or choice, your first instinct should always be to ask if they are actually opposites or if you can also have both if clever.
I made an account on HN because this is the worst post I have ever read here. NO!!!! DON'T USE CUTE NAMES!!! I am currently working with a big company for my apps and it is full of cute names which are the biggest problem for me. To launch an app you have first to integrate the Zaamla-Service into your IDE. Then just patch things up with Pimble, upload the signed HIMA-Package into the Katala and activate after that Z…
I find naming to be one of the most bikeshady of activities.
Pick something and move along. The more you think/argue about them the worse the outcome.
Channel your first instinct but be ready to change it once it turns out to be wrong.
I made an account on HN because this is the worst post I have ever read here. NO!!!! DON'T USE CUTE NAMES!!! I am currently working with a big company for my apps and it is full of cute names which are the biggest problem for me. To launch an app you have first to integrate the Zaamla-Service into your IDE. Then just patch things up with Pimble, upload the signed HIMA-Package into the Katala and activate after that Z…
We use pretty much random names for our servers and other hardware, but all of that is abstracted so during normal operation you don't even know what thing you are using unless you want to for some reason.
I am not really for or against using names instead of numbers or whatever, because I should never even need to care if things are done right.
Names should be cute AND descriptive.
His point is good though. Descriptive names add overhead that might need to be changed.
Giving something a cute name but describes its general purpose, means you have a lot of leeway, but if you get to the point where even the general name doesn’t work and you want to change it, then you actually have a new product and creation is better than evolution when it comes to software.
Joey, the small service that hops from one place to the next in what seems like ~~ab~~an endless loop, is like a baby kangaroo, and it can even grow into a real kangaroo and do whatever they do, but it isn’t gonna become a fire breathing dragon, and if Joey is trying to be forced into being a dragon instead of a kangaroo, well maybe it’s time to start from the beginning and decide which programming language to use ~~snd~~and go from there.
Think of it, instead of writing software, we just write fantasy stories, and the software that tells the story is our product.
I don’t know about you but I could probably come up with some cool stories of Joey the baby kangaroo.
I’m going to start a company and name all the services and APIs supporting the software after the best characters from mythology, and just start making good characters and then figure out where they go in the story.
The story is already written, but the characters have to be fleshed out.
Nice theory. In practice all this does is make it harder to onboard new people. Quick test: It's your 2nd week on the job. Some core system just went down, and you've been assigned to figure out what service is causing the trouble. What makes for easier, more transparent reading of error logs, the name "ServiceRouter", or the name "Trainstation"? It's not just a matter of the name being perfectly descriptive for any…
Another fun story I recall happened when server technician had to replace faulty HDD in RAID array. We ensured that the serial numbers were correct in correspondence yet still technician replaced the wrong one. When we complained we got into funny argument that we should use color code to designate HDD. Serial numbers are hard to pass and easy to confuse (especially since they were next to each other). But color coding wasn't provided to us, customers - we couldn't use it even if we wanted to.
Naming is hard but descriptive name doesn't guarantee correctness or helpfulness just as non-descriptive wont ease understanding or improve communication without proper directory or conceptual mapping. Does DatabaseServer-EU-259-aed6f give more information than "dumpstation" in scenario where it relates to single server wordpress blog.
In the end it's still about difficulty of naming, middle ground and consistence. Ubuntu for years used letter coding with animals and it worked. MacOS uses naming scheme for releases even though iOS and iPadOS are numbered only. Some people would be confused that Windows 95 is after Windows 3.11 and before Windows 10 and Windows 11. Not sure if Docker still use cutesy auto generated names for containers but it was fun to use.
Naming is hard.