[flagged]
Flagged to death. Sigh… Kinda proves your point.
Probably because it appears they are fishing for a political fight, and they are referencing their own vaguely related post from four days ago as if someone else wrote it ten years ago.
Names should be cute, not descriptive
21–30 of 498 posts
Re: Names should be cute, not descriptive
#22They’re both right, of course — the author and his colleague — and this blog post makes an excellent point as to why.
I will switch from descriptive to cute once I’ve reached a certain level of abstraction. That level can best be defined as the level where I will need to start advocating for the idea with other engineers.
A new ssh wrapper for automating access to the manufacturing robots? example.factory.sshtool
A log file parser for extracting text-only errors across multiple robot.log lines into structured error objects? example.factory.logs
A quarter-long project to build a new abstraction over all our thirteen different categories of manufacturing robot we have deployed on site that replaces a bunch of shell scripts written by the former CTO, and then actually replace all those shell scripts with the new thing, with tests? example.factory.duckling
I’d promote it as being named after how ducks imprint on their mother and follow her lead. Kind of a nod to the robots, but also to the former CTO. Cute names can feel a little saccharine but it really helps build advocacy obviously — it’s ultimately a branding / marketing exercise.
If you do that day-in day-out at the level of the ssh tool or the log parser — projects that should ideally have a low level of controversy compared to the shell script rewrite — then people are going to get annoyed with you.
Re: Names should be cute, not descriptive
#23When a bunch of those names accumulate, you pay a high onboarding price, not only for newcomers, but also for people who don’t read your changelog.
- Oh, _gfuby_ can now monitor my instance in production in addition to being a code versioning system!?
Re: Names should be cute, not descriptive
#24Descriptive name guards from feature creeping because every one understands the scope of service. If it is always tempting to add new features to the existing services, creation of new services should be done to be easier.
You really think a name is going to hold anyone back from this?
Re: Names should be cute, not descriptive
#25Cute 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 there are probably several policy related services.
Re: Names should be cute, not descriptive
#26Just don't apply this to variable or function names please, thanks!
What? You don't want to sift through hundreds of pokemon and anime characters names totally unrelated to the variables and functions of the API you need to use for your job? I'll just write "not a team player" in your annual review.
Re: Names should be cute, not descriptive
#27While scope expansion is a potential issue, a service by its nature should not inherit scope outside of its core responsibility. If it does (an auth service with some type of user information is clearly taking on more scope than it should), a practical name will reveal that right away.
The issues with practical names mentioned in this article are pretty small when compared to the very real issue of understanding cute-named services. If AuthService goes down, I know what that means. If Balthasar goes down, I now have to understand what that is, look up documentation, find the right team, etc.
Re: Names should be cute, not descriptive
#28Cute 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…
>Yeah but surely there is a directory somewhere that explains this?
No, there's 5 different directories in 3 different formats compiled across the last 8 years representing the state of 80% of terms at the time it was last updated, half of which disagree with another version.
Re: Names should be cute, not descriptive
#29Baby, meet bathwater. "Names are hard to change" is supposedly the reason to give things meaningless random names. Great, now you get the worst of both worlds, the meaningless name is now synonymous with a purpose (the very thing you tried to avoid, well, tough luck, that's not how human psychology works!) AND newcomers to the company/org will have zero idea what "galactus" and "goatpen" are or what they do.
Re: Names should be cute, not descriptive
#30Interesting, cute even. But I will stick with boring law firm names.
Firstly when I was a so-called manager cute project names were a nightmare - who could remember what "project mayhem" was - lift and shift half the the data centre or was it refactoring the stupid accounts hack. Project refactor-accounts-monthly-charge is something at exec level everyone can remember. It's fine for project-negotiate-possible-sale-of-dutch-office to be called project mayhem, because powerpoints get acciendetaly shared, emails get read, but there aren't many of those.
Secondly Sam used to be called Sam Smith because he was the smith. If he becomes used for something else people will create a directory (in their heads or in reality). And that's the key here.
Directory services are way easier to manage