Software component names should be whimsical and cryptic
medium.com
medium.com
Whimsical project name? No problem.
Whimsical type name within a project? Really bad idea.
Whimsical variable name? Don't even think about it.
The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and variable names, however, is set by the standard library and these are almost always descriptive. Their purpose is, in the best case, to reinforce a ubiquitous language drawn from the domain.
Boy, I wish!
I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.
So clearly, it wouldn't be "Asparagus", it would be "Beef" (as in Kobe).
How are we going to notify those 15? Do we even know who those 15 are? Are we going to create a weekly redefinition newsletter?
I think in most cases new meaning deserves a new name. Everything else is just hacks.
How hard is it to change a name is a actually a really good metric for a company. If a simple rename takes several days, multiple approvals, rounds of QA, and a scheduled release next quarter, then you probably need those hacks.
I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.
Half the article is like, "There was a component called YamlParser, which is now a browser-based stable-diffusion renderer!"
They didn't change names, but their successors would get a new one.
No idea which way you're arguing though! ;)
I can't say how the name was chosen. But, I believe I understand the justification for it. It is pretty straightforward once the metaphor is clear. The files it is making are the type of files that go into filing cabinets, not the files on a computer. Early versions of the software had a logo/picture of a building that was a giant filing cabinet and the app logo has usually been a filing folder.
The name makes sense in that isn't about making files on a computer but to help small business convert physical files found in filing cabinets into digital ones in wysiwyg database.
I remember finding "Photoshop" nonsensical at first because I associated a shop with a place to go buy things and it only made sense once I made the association that cars and such are taken to the shop for repairs.
Especially this bit:
Bedazzling Names
Choose variable names with irrelevant emotional connotation. e.g.:
marypoppins = (superman + starship) / god;
This confuses the reader because they have difficulty disassociating the
emotional connotations of the words from the logic they're trying to think about.There are a lot of Google and Microsoft programs who implemented his "advice" (i don't use Apple).
Even though I played the game I was pretty lost in that codebase. People that didn't play had no idea what anything did.
The author is very clear about this matter.
bitch_please
I invite spirited debate on this change request.
Is it an attempt to police the behavior of the async runtime? As a non-mainstream user of a minority language with pluggable runtimes, do I have the right to reappropriate this word?
Perhaps we can develop a language standard for async priority variable prefixes and suffixes. Removing it from the domain of library convention to language feature.
We currently utilize function parameters as the only input to functions, leaving a powerful source of information untapped on the left-hand-side. Will this change speed up development, or more likely, introduce errors? Will advances in language development environments reduce that concern?
How about: bitch_please, bitch_now, bitch_after_next_slice
Note how the meaning of the variable changes with bitch_now? It feels more uncomfortable doesn't it? Less of a joke. Ignoring the runtime's own priorities and values changes this. But why is it less funny? What does that reveal about priorities and still-existing prejudices in LANG? Does that mean that the original use is also less funny in certain contexts, such as public spaces?
Alright, change withdrawn, I was wrong.
* This isn't an original joke, but it is further refined. * I could have been a good academic or scientist.
There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead.
p.s. Obviously does not apply to brand names, which need to be distinctive.
p.p.s. Rich Hickey talks about this here: https://www.youtube.com/watch?v=oyLBGkS5ICk
It may well fit that use case to add one extra feature to the library rather than creating a new library.
I suspect that many of the examples provided (such as the Django project) evolved over time. It can also often be the case that once an implementation is done it becomes obvious that it actually does something very different to what you originally set out to do.
If it's painless to create new internal products within your company & there is operational support for it, you're more likely to spin up a sister "EmailNotificationService" alongside "SmsNotificationService".
If you have to jump through hoops to get sign-off and business cases etc and eitherways it's the same team responsible for both, people are more likely to say "let's just put the functionality in here"
That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like:
- css-min
- css-polyfill
- css-inline-min
- css-inline-polyfill
- css-script-min
- css-script-polyfill
- etc.
Good luck clarifying what you're talking about. And of course, people will start using acronyms for all of them, and now you're back at cryptical names, with the added benefit of all the names sounding and looking similar. Or, of course, have inaccurate or inconsistent names.
And then I didn't even get to the part where your categorisation turns out to not match the eventual scope, and they'll need to be split into css-server-min, css-client-min, etc.
https://qz.com/646467/how-one-programmer-broke-the-internet-...
What's hard to distinguish? These are projects that do something with CSS. If you don't need css, you skip them. If you need a polyfill, you only look at polyfill ones to see what you need.
Now, let's imagine your list is "creatively" named like
- shelob
- arcana
- custard
- escalope
- virtuocsso
- jester-css
- etc.
Ah yes, this is so much easier to distinguish, isn't it?
And definitiely not inside the company I work at
Edit "And I will never know love because of Galactus" https://www.youtube.com/watch?v=y8OnoxKotPQ
If you want to make new and different things, just do that.
This is a thing people like to repeat over and over again, but just really isn't actionable. The world is very high dimensional, it's always a judgement call what to cluster together and call "one thing". Especially in software where everything is made up and is constantly changing.
People often like to refer to things like unix tools etc as doing one thing and doing it well, but all those tools have grown a ton of command line args, and have backwards compatibility issues that prevent them from doing their job "well" in the modern era. So people write new tools or just hardcodes a ton of command line flags into aliases by default. Many default settings on unix tools are awful. Why does grep not use regex by default? Why doesn't echo support newline escapes by default? Which tools use color by default?
Reality is a mess, and it's an illusion that you can do "one thing"
If it's called Vue, I'm going to think it's big enough that someone thought it was worth it to spend an hour thinking of names. It was intended to get big. This isn't some minimal internal thing for one specific use case that probably isn't mine. I'll be more likely to check it out.
They also limit the scope of a project. If you have a "datasender" people will say "This shouldn't preprocess data! This shouldn't compress! This shouldn't intelligently decide when to drop frames! It should just send!"
Now you gotta have a separate frame droppy preprocess thing, and the part that does communication has to tell it what kind of loss you have, but even that is not just sending data, so more likely you won't get that feature at all, or you'll have to go beyond the name.
If you hate features I guess it's a good way to make them hard to implement.
Short names, like "Gru" were reserved for the most powerful trolls because there were only so many combinations of three letters. Long names on the other hand were a sign of weakness and cowardice - bringing ridicule to those who introduced themselves like that.
[1]: or rather, if they were longer, the first 8 had to be unique.
After all hackers were always - by and large - weebs, with their fascination with martial arts and Japanese culture.
Compare: "Nile Online Frameworks"
No simple name can describe the job 100% after a certain level of complexity anyway.
Those are synonyms. What is your point?
I mean it could’ve been “RedHat Cthulu” and “Amazon RainBox”.
I'm assuming this is a tool for quickly laying out and publishing books. Or perhaps a tool for quickly searching for and downloading books to my iPad or ebook reader.
But accounts and bookkeepers all know what QuickBooks is and are quite happy to not have to explain to their clients why they need to spend $75 a month on "KowalaBabyPooPoos" or something equally ludicrous name.
Which is the point which you probably didn't miss in the first place.
[1]: https://xero.com
I think part of this is that in software ecosystems that have been around a long time, the most obvious descriptive name for a package tends to have been chosen by the package that got there first but is now has an API riddled with outdated anti-patterns and whose code hasn't been touched in a decade because eventually everything becomes a breaking change.
The newer package has to pick a weird-but-available name, but has the luxury of rebooting with a cleaner, simpler API and an implementation free of "bugs" that must be kept around in the name of backwards compatibility.
Once you experience enough of those, you subconsciously develop an association that "boring obvious name" equals "crappy API and weird behavior" while "weird random name" signals "nice modern API and coherent semantics". Of course, it's not always true, but humans are voracious pattern matchers and will create an association at the slightest hint of correlation.
> Even worse are those ubiquitous diagrams everybody uses to communicate about software, where there’s a box labeled OrdersService with an arrow connecting it to a box labeled OrderStatusService. I don’t understand why anybody draws those.
People like this are why there are documents with a thousand bullet points and no diagrams to help anyone actually visualize how this all fits together.
It's like a children's song ...
The foot bone connected to the leg bone, The leg bone connected to the knee bone, The knee bone connected to the thigh bone, The thigh bone connected to the back bone, The back bone connected to the neck bone, The neck bone connected to the head bone
And by the end of it you still don't know what you are dealing with.
Personally I prefer UUIDs for global uniqueness.
c88990d0_c47e_4d8a_aa96_680d8b58192d_Service aka OrderService
ca7f6516_337c_11ed_a261_0242ac120002_Service aka PaymentService
Already have Service and need Service? How bout NewService and Service instead. Or ${NEW_TRAIT}Service and Service. (can replace Service with any domain)
You could also just not duplicate and keep a single Service. Like other mentioned this is likely a design problem at any point names clash.
Business owners and product managers tolerate the whimsy when systems work, but then suddenly when you can't make a feature commitment to a customer on whose relationship your business growth depends - because of the tech debt you accumulated by not priortizing UnicornPoo in your engineering roadmap, you realize your engineering team has essentially betrayed your organization so that they could be lazy and focus on science projects, and the code names were to obfuscate their commitments, and as an expression of spite and contempt for the people they took money from. Whimsy is cute initially, but it quickly becomes uncanny, and even repulsive to see adults acting careless. Cuteness is how children bargain with nature, and in a corporate environment that is about the livelihoods of adults, it is a liability.
That way, they're both whimsical but easy to remember, and if they drift a bit, it's fine.
"Always give cute names", "Always give descriptive names", "FP is always good, OOP is always bad", "Always test first", "Always test later" etc.
Golden laws don't exist: Pick the best solution for your current situation and accept that your current situation will change. (Which is, again, a trade-off between now and the future!)
It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement.
What is easier to understand at first glance?
Picard stopped responding to Luke. Bilbo is also down!
or
PaymentService stopped responding to UserService. Database-XYZ is down!
It might not be exciting but the cognitive load is much lower.
This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"
You have bigger problems if your `PaymentService` morphs into the functionality of being a storage or user service.
And if you having a payment system that starts doing something payments systems traditionally don't do - like, I dunno, predict weather? - then you have a design problem and should refactor your system so your payment system doesn't do that anymore.
PPS stopped responding to UDMS. CMS is also down! No, not the CMS, the CMS is fine… CMS-the-service is down!
The result - well, it works in some respects, but it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer, or that it plays much role in getting the right prescription into the right medicine cabinet and ultimately, patient. The names are confusing as hell, often unpronouncable (despite the orthographic and oral qualities of the names being considerations in name assignment) to anyone who doesn't know them well, professionally. And the common drugs - well, let's just say, you're far more likely to tell someone you're on Lipitor (a brand name, for marketing) than "atorvastatin".
> it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer
In this case I don't think you can have the cake and eat it too, unless you can somehow prove that the chosen descriptive name will forever remain meaningful and descriptive.
The part missing here is that there's a doctor in the middle that knows about the "atorvastatin" part, and that's usually who prescribes you the Lipitor.
Another part is that the name should be a) unique, so you could make it a trademark, b) distinct, so the patient won't tell their other doctor they take a wrong drug (less important now with electronic databases but still important) and c) shouldn't mean anything to the patient, because they aren't the one deciding whether to take it or not - but they will be the ones taking it.
That's usually not the case with software packages. Of course, sometimes it is the case that the manager decides to buy software because it sounds good without technically understanding what it actually does - but it's not a common case, especially for more technologically complex software. So the naming considerations here are very different.
a) The official (that is, generic) drug name is guaranteed to be unique, but they cannot be trademarked. That's one part of why drugs are typically marketed under names other than the official name ("Lipitor" is a market name, "atorvastatin" is the actual drug name).
b) Most patients don't know the names of the drugs they are taking, and what they do know are as often as not, not the official name, but a marketing name. Ask any doctor why they ask patients to bring their prescriptions with them to office visits (hint: because in m any cases, it's the only way to get an accurate picture of what a patient is actually taking.)
c) I don't follow this at all. It's a bad think that I know that the three drugs I take are a diuretic, a beta blocker, and an angiotensin receptor blocker?
I think it's interesting to compare drug naming with other medical interventions. We don't call a Laparoscopic Cholecystectomy a "gandalf" or "vartafoprodson." We use medically meaningful names. Why is "losartan" better than "angiotension receptor blocker 95-1" (first ARB approved in 1995)?
> It's a bad think that I know that the three drugs I take are a diuretic, a beta blocker, and an angiotensin receptor blocker?
No, it's not a bad thing that you know that, it's just about 99.999% of people have no idea what a "beta blocker" is. So for them that information is completely useless, moreover, if they plan to act on it, it may be dangerous, because they may confuse "beta blocker" with some other "blocker" and make some important decision based on that, without understanding the real consequences. If you are knowledgeable enough to know what "beta blocker" is and how it works - sure, it's useful for you, but vast majority of people don't know that and never will.
...some of the time. The rest of the time they're actually very useful. Giving up any attempt at having a descriptive name just in case you get it wrong is throwing the baby out with the bath water.
What's probably happened with a lot of poorly named projects is that when the scope changed to make the name redundant there was no attempt to change it. People get attached to their project names. It's possible that changing the name would require some effort, and maybe some cost (losing Github stars maybe?). That makes people stick with bad names. None of these things apply in a company. Just change the project name to reflect what it does now.
Try to come up with descriptive names for projects like Git, Node.js, Docker, well, Linux. Well, BSD is formally a descriptive name, but it elucidates little.
Of course there are some examples of somehow descriptive names which seem natural because of the sweeping success of the product: Photoshop, React. But they are few and far between.
In short, project names are closer to branding than to engineering.
Inside a codebase names should be descriptive, and appropriate effort should be allocated to name key things in an elucidating manner; nothing to debate here. But it's a very different context.
"Problem" solved!
Afraid of losing stars/dlds on the repo/etc? Make it clear in the Readme where the new project is. Have warnings et al for NPM projects.
Ask npm/GitHub to allow name changes with redirects.
This proposed "solution" is just bad for many reasons:
You need to delve into the Readme to find out what it does. Imagine you're seeing a package.json and for each line you have to Google what's the project about
SEO is best if name matches.
These are enough *good* reasons why this advice is a bad idea
Whoever named the ML thing "transformer" deserves a special place in hell. So many intriguing headlines, so few things worth reading. (I'm an EE, so I'm very interested in the other transformers. For some reason, the headlines for these things scan like they could apply to either. Alas, they don't.)
Your complaint is similar to cryptography conference attendants hating the word ,,crypto'' to change from cryptography to cryptocurrency, but that's just the natural evolution of language with technology (not mentioning that the original meaning of the Greek word is hidden/secret).
It's not the first time something like this happened, the only difference is that in the past languages evolved similarly in hundreds of years, now a new word can pop up in a day (but most new words get global in just a few years).
If it's a product, by all means think about brand including a creative name. Might be vaguely related to the service, like YouTube, or completely wild, like Starbucks.
If it's mostly a tool, being descriptive is just good SEO. You are not ever becoming a "household name" with a recognizable name when you are just supplementing a library supplementing a framework (or similar), and there is no reason to strive for that. "Django REST framework" shows up naturally when I google "django rest" and that just benefits both sides.
If you are in between the two, opt for the middle: TweetDeck, MailChimp.
That's my two cents anyways..
I feel almost like there's an analogy between choosing names for packages/projects and bird calls. Birds need to make their calls stand out in a given ecosystem. If you have a dozen projects like, say, "object-mapper," "object-db-mapper," "object-mapping", "object-mapper-thingy", "object-mapping-service", "db-object-mapper", it's hard to remember wtf was the one you need. If in such an ecosystem your project was named "Orangutan," it might stand out and be noticed. OTOH, if all projects in a given ecosystem have weird names like "murano", "swift", "glance", "hotdog", "gorilla", "zaqar", "cthulhu", "funky-chicken", "Sauron" or whatever, it may be hard to remember what they all do/mean -- yes, I'm giving you the side eye, openstack. In such a space, "cloud-disk" or something might win, IMHO.
Slightly tangentially related is the use of odd words in log messages to aid searchability. I've been grateful for misspellings in the past, so I could easily grep for some critical log message containing `transation_id` or whatnot. (Good struct logging makes this less necessary, thankfully.)
The name itself comes from Dune, where the Bene Gesseret Missionaria Protectiva is itself whimsical (on some level) and cryptic. https://dune.fandom.com/wiki/Missionaria_Protectiva
A dashed arrow pointing in one direction is async data flow in that direction, A solid arrow is synchronous, and a swimlane / activity diagram shouldn't have two-way arrows in it (what would that mean?).
How is that more likely to be read wrong than source code? Doesn't match my experience at all.
Very bizarre ... also, why not BOTH a diagram and discription.
There's ~50, and nearly all of them are incomprehensible. It definitely makes things much less accessible to a newcomer / outsider.
(Trilinos is a set of scientific / engineering libraries for HPC)
Imagine a “UserProfile” service. It’s accessed from everywhere to show the handle name, address, icon etc. of your user.
Your application grows and your users want way more customization, now they get personas and avatars and can show different profile to different people. Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ?
Sound like it's better to make a new service. Isn't that the point of Single Responsibility concept?
Some of you are thinking, well, what if you need to interface with facebook dot com? Easy, I'd call it the SneedFeed. If you know you know.
Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.
From your point on versioning, I'd assume you'd actually call it UserProfileV2 ?
PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.
> PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.
From what it said in the original comment, it still seems like a user profile to me.
This way no one is misled by the name. Also, there is much less chance that an offensive name gets picked (either intentional or unintentionally).
There is also much less risk of collisions. In addition, you don’t waste any time trying to come up with a name.
"I try to step back and remember my first shallow reaction. The day I realized it can be smart to be shallow was, for me, a deep experience."
I am not going to tell you who this is, but the point stands.
The name should be easy to pronounce, it should zing, and your first reaction should be positive. Why do you have it? Doesn't matter. It's either there or it's not.
A good name is at least half of a product's success.
Naming things is also very important. Having some common language or way to refer to the various abstractions in the business is essential for basic teamwork. Even if the name is a cringetastic take on a comic book character. As long as everyone agrees on the string literal, you will be able to make forward progress.
If you aren't absolutely certain what something should be called (i.e. maybe you are prototyping a crazy new idea), just invent some crap to keep moving along. I've got a shitload of odds and ends in static classes simply named things like "Utility" and "Hack". When you aren't so invested in what something is called, I have found you are much more willing to get "creative" with it. Naming things can also start to imply some sort of structure, so keeping it flat like this helps reduce the cognitive load.
On the other hand, maybe you should consider more precise, deliberate naming if the business at hand is relatively stable and complex. Banking is a great example of a domain where very precise type names can make a huge difference in productivity. There is a gigantic difference between a "beneficial" owner and a "beneficiary". Applying reductive/creative naming schemes to this domain would likely cause more harm than good.
You can always rename stuff in the future. Even database schemas can be migrated over time without impacting live customers. You can even rename an entire company (i.e. Facebook => Meta).
I work on the same, but never learnt to use non-descriptive names.
It would get tiring to have to keep explaining to new team members that our prime number generator is named "optimus" even if it was initially clever.
I don't look forward to convincing my boss we need to pull in "libAnimeBabe" as a dependency even if it's the best parser for a file format we need to import.
Nobody wants to find out a year after all of our marketing material is put together that our software name means "asshole" in another language.
Don't make me have to pronounce an unpronounceable Gaelic word every time I do a presentation on our software stack because you're Irish and just had to name your component that way.
There are lots of ways "whimsical" can backfire unintentionally. Save your creativity for the actual software solution.
I also kind of disagree that an "unpronounceable Gaelic word" is a poor choice. Seems like cultural discrimination. People all over the world write software, not just people who can pronounce English words.
Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects/services as they want, and organize everything based on whim. You get this: https://www.youtube.com/watch?v=y8OnoxKotPQ
For me that is not a parody, it's lived experience.
> I’m probably being overdramatic there, but I hope my point is clear. “Descriptive” names don’t create transparency, they create the illusion of transparency. If you see that something has the name OrderStatusService, you will instinctively assume you know what it is and does, and you will probably be wrong.
When what a thing does changes then the name should also change. I almost want to counter this Medium post by arguing that READMEs should be works of fiction because the project they describe might change over time.
I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will say that funny names are not actually fun.
I can only imagine working in the author's ideal company:
"Hey, does anyone know why Shmoop is down? I know I updated the BoomBoom and reconfigured Thanos, but now Klomgan is reporting a series of Lemonhead warnings. Should I talk to Meep team or the Chumbawumba admins?"
https://www.youtube.com/watch?v=y8OnoxKotPQ
I'm completely with you that name choice is not necessarily where something needs to be fun, and most people don't realize that once you name something, it's probably around for 5-10 years whether you like it or not. Or if it succeeds or fails.
I worked in a company that would "break ground" a new microservice every other week with overlapping scope of other microservices. (poor planning in resource allocation), which lead to some services named after Greek mythology that loose describes what service does...sometimes... Then they started giving more descriptive names, services that just do X and named X, except later they started doing Y, and now it's confusing.
Then we had service XYZ (abbreviated from what it supposed to do), it took too long to build, so naturally management decided to make a Z service and remove functionality from XYZ.
I think the author comes from a similar place where scope for service is constantly changing, and silly names are the only source of dopamine.
Upon the recognition of this is the time you should have your resume updated and you start responding to some of those LinkedIn reps that have been emailing you.
What method would you propose teams used to name a project, in which "fun" names are discouraged?
Maybe "whimsical" isn't an accurate moniker. Generic or Common is how I would label the naming strategy described by this article. "Whimsical" is just asking for trouble and opens you up to overtly stupid names like "Chumbawumba."
The article says "names should make you smile." And really, does anything make a person smile more than Chumbawumba? They get knocked down, and they get up again!
The what?
The what?
And the what?"
Choosing whimsical names is a pretty good way to satisfy my two most important requirements. They are often unique and don't mislead people.
Of course my ideal name would also give some hint about what it does (I think Google's BigTable may be one of the best named products) but I think this is far less important than the other two requirements.
Software should be fun! I love it when packages have goofy names. If I can shitpost with the language I'm going to get just a little more invested in it.
And to be honest, even the 'serious' names fail at connoting respectability to begin with. Your grandpa would get annoyed just hearing the word 'containerisation' - and not just because he thinks computers are for nerds. The word sounds silly. People are saying this silly word at conferences and the word is still silly. So why not lean into the goof?
When I think of programming things I use the most, most of them have whimsical names that mean nothing.
I mean, say, “grep” means… something with regular expressions I guess? But nobody cares. It’s just “grep”.
I think most of that applies here. The whimsy & fun is cute at first, but it's rarely long term magic. For new teams & outsiders, it's a pain. I've had to work eith a sync engine where there's 20 subsystems seemingly each named by randomly picking a name from Encyclopedia of Mythology. There's probably something cute & creative & whimsical to the authors, but as someone trying to use the thing, it's merciless & oppressive, a huge turn off.
[1] https://tdarb.org/blog/death-of-personality.html https://news.ycombinator.com/item?id=32777411 (79pts, 3d agi, 63 comments)
I'm working with some legacy code that followed this pattern for internal services. It's a nightmare. WTF is Bilbo, oh it handles 2fa? And what's Pippin again? And there's a dozen other examples, of course most of them are from LOTR. I literally have to maintain a mental mapping because there's no rhyme or reason to the choices.
That's actively anti-developer, anti empathy and I hate it. It's not cute, fun, helpful, professional. I can't think of a single redeeming quality. Maybe it's ok for a prototype you intend to throw away because it's so ridiculous you don't want to use that name with your boss, so it encourages non attachment.
If you really can't pin down a name that describes the thing you're making, maybe you don't know what you're making?
Also, we can rename and/or retractor things. And we should if their responsibilities change!
Edit: added distinction about internal vs external.
The author here is equivocating opaque code names with multi-use repos. They're saying "see!? some repos on github do things in addition to their literal name."
That has nothing to do with the fact that obscure code names are a stupid anti-pattern.
There are only 2 difficult things in computer science:
1. Naming things
2. Cache Invalidation
3. Off by one errorsAnd it's not like "oops some gadget polishing code fell into my widget lookup service": don't put inappropriate crap into your solution. Little discipline goes a long way.
All the variables were global since there were not functions to pass things into and we had a problem similar to what the OP posted about using variable names that someone else might be using somewhere else. One thing we needed was `machine_type`. There were some references to `MachineType` and `machine_type` and `machineType` so, a colleague decided to use the name `MaChInEtYpE` to make it unique. For all I know there are still people who trip over themselves on the keyboard typing this while maintaining it.
I once created a PHP framework called RocketSled because it was “the fastest thing on rails” and that gave rise to somewhat whimsical but also descriptive names on the same theme:
RocketPack: package manager
DataBank: caching auto loader
Murphy: automated testing
Each of those modules is named quite specifically but that’s because they do one thing.
I created an ORM tool called PluSQL, because it’s not an ActiveRecord style ORM but adds a bit on top of straight SQL statements. General enough that if I want to enhance the functionality beyond ORM I can, but also pretty easy to remember what it does from the name.
The one library I created that may suffer from the problem described is Trellinator, which I recently began updating to work with the WeKan API, so maybe that should have been Kabanator … there’s still time.
But I don’t think calling them all after my favourite Futurama characters would have been a better choice.
"Following the end of hostilities, in 1947 Murphy attended the United States Air Force Institute of Technology, becoming R&D Officer at the Wright Air Development Center of Wright-Patterson Air Force Base. It was while here that he became involved in the high-speed rocket sled experiments (USAF project MX981, 1949) which led to the coining of Murphy's law."
I was very pleasantly surprised by this coincindence when I was looking for a name for my testing package to go with my RocketSled framework. I named the framework RocketSled before I wrote the testing package, with no idea about the history of the term Murphy's Law.
Interesting side note: murphytest lives on to this day as an NPM package, I still use the same approach to testing stuff now (ie. not worrying about any of the tenets of "Unit Testing", a practise which I called "Convergence Testing" at the time, but which probably already has a name, like Integration Testing maybe).
I'd argue that actually descriptive names aren't the worst thing ever, I wouldn't mind seeing a project/source code repo named "Client Bill PDF Generator" as long as the name on the tin actually matches what's inside of it. Of course, that implies that in the case of scope creep you should be able to change it as necessary.
What this avoids is the problem of not needing a glossary to figure out what "Shelob" is supposed to be in a list of 50 different services, though I guess if you wanted to go for something fun, might as well throw them together: "Shelob: Client Bill PDF Generator".
It's kind of how I approach naming my homelab servers/saving SSH sessions, a randomly chosen hostname comes first, but what it actually does is appended to the connection name/monitoring dashboard name - mostly because what I use the servers for might change so often, that this is one of the use cases where "fun" names make sense.
Actually, Dylan Beattie once described why "fun" names might make sense, in a conference talk called "Life, Liberty and the Pursuit of APIness : The Secret to Happy Code", though it also touched upon other aspects of development.
Here's the video timestamp for the problem situation: https://youtu.be/BIkXid_pBiY?t=769
Here's the video timestamp for the proposed solution: https://youtu.be/BIkXid_pBiY?t=946
The argument went along the lines of "by giving it a name, you cut out a lot of the noise". Curious, I can kind of understand that point of view, even though I'm not inclined to fully agree with it.
Judging descriptive names by their worst examples is not exactly a charitable interpretation.
In a team ecosystem where you probably need to optimize for readability and ease of use, try to be simple and accurate and get used to refactoring. Making up random shit is the worst advice I can think of.
For example, I tend to use a “layered” approach to servers. In one of my projects, the DB layer is the lowest, and is unnamed (it would start with “A,” if I had named it), so I named the DB connector “BADGER”[0]. The layer above that, is called "CHAMELEON/COBRA" (They are basically at the same logical layer).
[0] https://littlegreenviper.com/miscellany/forensic-design-docu...
I think if you expect you'll only need a small group of people to know the name (the "Shelob" example at a startup), or you expect a large group but only are adding one name to learn ("Vue"), it's fine.
The cute naming gets hard on larger projects. If you have to write a status or design document covering many teams, all with multiple cute names, that document will be impenetrable. It will be as hard as learning a new language - which in a sense it is, because your team will have created a new language that outsiders will need to understand in order to work with your team.
This is something I am very grateful for when I return to a project after some time away and the code is documenting itself.
But I'm also a fan of disposable code. If I'm actively working on something I probably rewrite more or less the whole project every 18 months bit by bit.
The original escape turned out to have character issues or so, so they made a new one: mysql_real_escape_string
We were hoping they would find another issue and release a mysql_real_real_escape_string
If your software is a "final product" which by definition can grow in requirements then it's best to use a creative name. So if you build a programming language, a build tool, a dependency analyzer, or any kind of software that has the shape of a tool; which the user can wield in a variety of ways. I'm glad we didn't call a hammer a NailPounder since it can do so much more.
One useful practice I've acquired over the years is to make the names unique. It makes it easier to search for them later.
Generally, I would lean towards descriptive names. If the name no longer fits the thing, that's a great warning about scope issues. If it sounds "weird" for other named things to be dependent on or be required by the named thing -- that's often a hint about a context issue.
I mean, there's a reason the old joke goes:
"There are only two hard problems in computer science; naming things, cache invalidation, and off-by-one errors."
For example, game engine. Some library or framework, that helps you to build games. Nice.
But what they do for you in detail isn't known, and can take months to understand.
Unity does much more than Phaser. Angular is a total different beast than React.
And this goes down to class names. MVC was the hype back in the days, but nobody knows what it actually meant in detail. Some people sat down and wrote some definition of the term, but no implementer adhered 100% to them.
Probably hard to get street cred for a cutting-edge processing monster named FluffyKitten.
Lucky you generally only care about release names within a single product because thinking which one is Jasper Lake and which one is Alder Lake is not something I want to do.
Even those product names are not excellent either: Intel introduced i9 which is essentially what i7 used to be and used to justify higher price - look i7 is the same price, but it's the brand new i9, that is totally wouldn't be called i7 5 years ago, that cost more.
My team work on a project with many "funny" names, including but not limited to, liboyster, libowl, several characters from Fort Boyard (https://en.m.wikipedia.org/wiki/Fort_Boyard_(game_show), patric the starfish....
It was awful to work with, please don't go that.
If you were to compare the total time wasted by each category, I’m sure nondescriptive would come out as the most wasteful by far.
1. Names must be descriptive.
2. Names must be unambiguous.
3. Names should be no longer than they need to be to achieve #1 and #2.
If your names are becoming less descriptive over time it's because you're not writing well. It's not easy to write well, but that's the job.
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Addison-Wesley Microsoft Technology Series) 3rd Edition
There's probably some cultural context I'm missing here, but I asked around in the office and got a different answer each time as to why it would be named like that.
That was 9 years ago and I still don't know BTW.
I mean if you go with cryptic then at least call it something short and obviously cryptic. "Chrome" good, "VersatileGopher" bad.
PS Yes I know that Chrome actually has an explanation, but it does not sound like it means something that you could guess if you thought hard enough. I'm also not criticizing Ubuntu release names because the context is obviously different.
I agree that bad and/or misleading names are, well, bad. However, I don't agree that we should just give up and name everything {SomeCrypticNameIThinkIsCool}.
Invest time in naming things well the first time.
Invest time in renaming things to be more accurate when it is feasible.
That seems like a bad example. I've often googled "cronjob foo" for how to schedule something in foo. Seems like "cronjob" is a general term for scheduling now.
if it's projects, ideally the long-term architecture is well enough understood to give the thing a whimsical yet meaningful name (ideally not cryptic). building a page caching service? call it gutenberg or something to start. when it inevitably grows past scope, it's ok. no one will care if gutenberg also handles analytics callbacks or whatever.
classes really shouldn't change in scope, ideally, so it's probably better to be a bit more specific to their purpose.
overall this is a good hot take, if a bit broadly put.
> If names are too clever, they will be memorable only to people who share the author’s sense of humor, and only as long as these people remember the joke. Will they know what the function named HolyHandGrenade is supposed to do? Sure, it’s cute, but maybe in this case DeleteItems might be a better name. Choose clarity over entertainment value. Cuteness in code often appears in the form of colloquialisms or slang. For example, don’t use the name whack() to mean kill(). Don’t tell little culture-dependent jokes like eatMyShorts() to mean abort().
> Say what you mean. Mean what you say.”
~~ Clean code, Uncle Bob
The fact that Arvo (the kernel) doesn't even have a distinction between RAM and disk, or between PCI input and network input, is a much bigger deal than remembering that "Arvo is the kernel".
OP is right that naming can give a false sense of familiarity, so inverting that for things like this makes sense. Create a false sense of un-familiarity, to keep the users paying attention while they learn what they are using. That's been my experience so far, a heightened sense of awareness while reading through the cryptic documentation.
Now get off my lawn!
Let's face it, no software company where any of us work has ever been satisfied with "well, we have enough features already, no need to build more." The incentives _always_ push for-profit software towards "build a shiny new feature", because you can't upsell existing customers the same features they already pay for, but you _can_ upsell them _new_ features.
So companies monotonically grow their featureset.
Companies also do _not_ monotonically grow their employee base, and _certainly_ not at the same rate as they grow their featureset.
So, for example, the "email send team" of today will probably become "the email sending and rendering and link-tracking and some-of-the-reporting-but-not-all-of-it and some-of-the-public-API-but-not-all-of-it" team before long. And they'll probably also gain additional features along the way, some of which are likely to be even _less_ related to things like SMTP and MTAs (which they'll still regularly have to deal with).
In the meantime, those "some-but-not-all" categories will be shared with other teams, usually in a way that's not neatly describable in 1-2 words.
So do you keep constantly changing your "descriptive" team names and fleshing them out into entire often-mutating paragraphs so that they're _actually_ descriptive? Because you're _certainly_ not going to wait to build a feature until there's a new team for it. And what happens when you decide that some of those features should change hands to a different team? Time to go update all your CODEOWNERS files and ACLs and directories and everything so you can change the team's name again?
Or do you accept that memorable-and-unique-but-not-descriptive team names like "Apollo" or "Wombat" are a better use of your time, and find other ways (like relating per-feature PagerDuty "services" to team-level escalation policies) to map "feature X is currently owned by team Y"?
Because honestly? 70% of the time that you would want a "descriptive name" for a team, it's because you're trying to reach/page the right team to fix a problem.
Set up feature/service definitions in your tools of choice (PagerDuty, Jira), and make sure those are many-to-one with the team definitions, and then ensure that those definitions can be easily modified/reparented later.
To put it in programmer-friendly terms, don't use magic strings, factor out real identifier constants, and reference that constant instead of duplicating it.
P.S. to those of you who might say "you can just pick a generally-descriptive-enough name without it listing every feature", I once worked on a team named "<Product> Email Team," and we _frequently_ got questions/tickets/bug-reports about email-related or email-adjacent features that were actually owned by other teams (either on a different product, or as more of a "downstream" thing). We also sometimes _didn't_ get questions passed our way that were related to the non-email features we'd accumulated over time (see also: featureset growth speed vs. "headcount" growth speed). We were eventually renamed "<Product> Email And Content Services Team", ironically because our existing "descriptive" name was deemed "insufficiently descriptive". Rather than fixing the problem, the new name in fact only exacerbates the problem, since no two people can clearly agree on what "Content Services" are.
If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing a design up-front, or drawing diagrams of how your system works, then this indicates one of two things about your background.
1. You're a relatively junior engineer who has gotten used to thinking about productivity as slamming code that tweaks existing systems into new incremental features
2. You work on some fucking web service.
Either way, your advice does not apply to the software engineering profession as a whole. Believe it or not, lots and lots of people write software, and not all of it is a web service or some tool / framework to help run your web service. There are many things out there are that can be envisioned, designed in detail, and implemented. And, crucially, in those cases, _it is wise to do so_.
I know I'm being overly dramatic, but it consistently enrages me reading blog posts that, through ignorance or deliberate omission, speak as if the world of software is just writing web services.
Or, it could be that you're actually innovating and requirements are changing faster than you write code.
A late change in requirements is a competitive advantage.
There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.
Have you heard of brainstorming? The worst thing you could do is to ban mistakes.
Innovation is doing something that hasn't been done before. Inevitably that leads to mistakes.
Being sloppy also leads to mistakes.
Presence of mistakes doesn't tell you much. But lack of them tells a lot.
If all your experiments are successful, it doesn't mean you're a genius. It means you're experimenting too slow.
And if you just happen to change it eventually, it's best for everybody if you go and make it a different project with a different name. Descriptive or not.
Sure constantly changing in the complete opposite direction is probably a sign of something wrong, but changes are inevitable and we can’t expect to reinvent the wheel or start a new project as you say when you can potentially reuse what you already have.
So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.)
The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.
The one important thing is that if you decide you must solve some completely different problem, you should do it with a completely different product.
So the argument that a nondescriptive name allows you the freedom to change the product is bad. You never have the freedom to change the product.
This strikes me as a false dichotomy. The choices aren't limited to "BDUF" OR "NDUF" (No Design Up Front). There's a continuum along which the amount of up-front design that is required can range. I prefer the term SDUF (Sufficient Design Up Front). And of course we all have to keep in mind that design and architecture aren't things that only happen "up front". Design and architecture work-streams should continue throughout the lifecycle of the project, IMO. The relative weighting of the different work-streams can vary, but the key is that it doesn't just end after the first (iteration|sprint|phase|whatever-you-call-it).
FWIW most of our deadlines are reasonable.
Often times when people get creative with names, the meaning dies with them. When they leave the company so too does the reasoning behind the name.
The author conflates service bloat with bad names. Fix the bloat and the name will make sense. If you have an app called “Authorizer” and it does email, you failed. If you have a service called “InfraValidator” all it should be doing is validation. If it’s not (such as tensor flow’s infra validator) then the service/app/codebase is misleading and needs to be renamed after what it does.
I also hate to see overly descriptive names. Package/crate/bundle/module should help classify the name of the class/object/func_collection.
Names like “EnvironmentPostProcessor” (Spring Boot) is succinct enough to know exactly what it does. It processes environment vars after a stage.
It’s up to principal/staff engineers to make sure that the components of the system stay lean to its purpose. They should be able to say “oh, we need to send an email when this happens? Here’s an email service we can use” that doesn’t introduce feature creep into AuthTokenValidator.
I get what you’re saying but these little shortcuts (adding email sending in AuthTokenValidator) cause enormous tech debt later on when you scale.
But many software projects are. not. that. That's really all I'm getting at. This web service developer bubble annoys me because they never feel any onus to introduce themselves in their blogposts and caveat their opinionated recommendations with the context they're coming from. In my world of robotics, just making a random family of services with non-descript names is a bad idea. The services in the system should have roles, and if the temptation arises to add functionality beyond that role, it probably means you need to step back and do some thinking about why that happened.
Also: I know you were just making a rhetorical point, but notice that your example is still clearly some web service that we're assumed to be running :)
I'm gonna close the Internet for today because you, sir, just won it
I'd assume everyone here could at least agree that naming is hard. I don't think the article was attempting to explain how to name, but instead point out one potential pitfall when naming.
That's fine though. Anything you work on will inevitably develop a personality in your mind beyond what the name literally means, so what's the difference if the name is something like GAS (generic-acronym-service) or Fuel (GAS > gasoline > fuel).
A persuasive dev at my last job tried to insist on non-acronym names for every new service, and 5 years on, I can still remember every proper name, but none of the acronyms. That, to me, is sign of a good name.
The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and just backronym it). This isn't a new idea. Lots of greybeards know this and name stuff accordingly.
But in OTHER contexts, your software components might be more like organs. If the heart has also become responsible for digestion, then it indicates your system design needs to be revisited. In lots of software projects, this is not an untenable proposition, such as it presumably is in a web service company.
As somebody who works in one of those other contexts, it's important to me that the web service monoculture be correctly contextualized. Otherwise you have people cargo culting it in situations where the wisdom no longer applies. That's probably why I'm being so bitter. :(
If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothing web-development-specific about that. Big projects get Name-names, like companies or people. Always have.
And yeah, all of them start at zero lines of code and zero users. Naming things sucks, but renaming things sucks worse.
"Software component" has the connotation, to me at least, of being an inward-facing _piece_ of one of these products. It is but one component of a system, and thus it is to be understood by its function within that system.
I think in many domains, the best advice is to name those components helpfully, and to think about the component's role in the system. To start adding functionality to the component outside the scope of its name is to invalidate your design. There is no reason to bloat this component. You'd rather create a new component to handle the previously overlooked role in the system. This is made obvious when you take limiting cases, like designing a moon lander. Here, the software design must be purposeful and optimized, and it only needs to work once. In the opposite case, the component is a web microservice - a living thing managed by a 1-pizza team that always needs to be turned on. Uptime and speed of implementation are at a premium, and creative ways to add new functionality on existing systems are seen as a net good. Here, the article's advice might be good.
You've stumbled on yet another situation where you should give something a cute name instead of a descriptive name: If there will be many implementations of the same thing over time. Each generation of Intel processor, each sort algorithm (TimSort, thanks Tim), each rocket, each mid-sized sedan.
Now, do the individual software components within a moon lander get names? That depends! Are they re-used between landers? Are there many different implementations of the same component to choose from for each mission? The more affirmative the answers to these questions, the more likely it is the component will have/should have an actual name, instead of just being, say, "allocator.c".
There are just so many reasons you might want something to have an actual name. Competing implementations or historical implementations, userbase size, project longevity, researchability. And they're all subject to change in the future (and renaming sucks). I have a hard time faulting anybody for giving their little binary data format a name like "parquet", even if it's tiny and only used in one place by one other thing and might never have any users. Because it might end up used for a long time, or by many people, or in a period of competition with another implementation of the same thing. If any of those things comes true, you're going to be glad you didn't name it "Hierarchical Data Format".
The author actually does discuss the nuance. They argue exactly your point saying that their “considered harmful” advice only applies in situations where the scope of the component is ambiguous/fluid/unknown/otherwise prone to change over time/etc. In cases where you have a mature fixed design, choose an appropriately descriptive name.
I’m glad you have only ever worked on projects that were perfectly designed up front. Sounds like the dream. For the rest of us, we engineer in reality. And I find the author’s point apropos.
So true. Web services are just a distraction from real software, which is writing compilers.
In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge problem space and I don't understand calling that "bs." Active Directory would like a word...
A web service. Not a moon rocket, or an MRI machine, or high frequency trading software, or computation fluid dynamics simulations, or a compiler, or a video processing pipeline, or a word processor, or a 3D game engine.
So, just saying: When bloggers consider the headline "Software component names should be whimsical", I wish they'd spend a second to ask themselves whether their advice actually applies to any of the niche domains I mentioned, or if it's just a best practice for their fellow web service developers. Presently, there's a cultural trend that you don't have to bother with that step, and you can just write as if your audience is always the other web service people in the valley. To me, that gets very grating, and that's where the snark comes from.
However, consider whether your original post made that critique clear, or if it got lost amidst the other ... stuff. The first two lines, in particular, will immediately put some readers (myself included) on the defensive. Describing somebody's work as "some web service bs" is a bad start. And if your point had nothing to do with the "hardness" of the problems, only that those particular problems are most relevant to building web services, why not just say that? Instead of the "...somebody who works on some web service bs assumes that that's as hard as the world gets," bit.
Also, please don't fulminate in HN comments.
How can you expect people to follow these rules when you yourself don't? Looking at your history, you[0] leave[1] comments[2] like[3] this[4] (shallow dismissals at best, and snark at worse) pretty[5] consistently[6]. What gives?
[0] https://news.ycombinator.com/item?id=32808611
[1] https://news.ycombinator.com/item?id=32807734
[2] https://news.ycombinator.com/item?id=32803087
[3] https://news.ycombinator.com/item?id=32799206
[4] https://news.ycombinator.com/item?id=32798437
For example, in this comment here that I’m replying to, you caveat what you say, and yet you don’t caveat any of the comments I’ve cited as ”your opinion”, despite them being the same value judgements of someone else’s writing.
“Please stop <value judgement of comment>.” Is about as textbook of a “shallow dismissal” as one could get.
You don’t apply the same rules to yourself, so there’s zero reason or incentive to follow those rules for the rest of us.
Edit: Hey, within an hour of writing this comment, I'm now slowbanned (a thing you at one point claimed was removed from HN). So I guess you don't like dissent either, dang?
Edit2: Since I can't respond (you muted me), the community doesn't evaluate your activity objectively; you're worshipped, and aren't give feedback that represents a reflection of your actual behavior, so an appeal to the masses here isn't an effective argument. The community may disagree with you, but it's actively detrimental to say so, and will apparently create negative repercussions for the folks who do speak out, creating a "chilling effect", preventing you from getting the "bloodbath" you apparently think would be necessary for you to change your behavior.
Additionally, the fact that you've made it harder for me to interact on HN as a result of this conversation is an indication that everything I'm suggesting here is even more true than I initially thought.
Slowbanning and rate limiting are two different things. Your account is rate limited. That's standard practice in a number of cases, including (a) when an account is posting too many low-quality comments too quickly and/or getting involved in flamewars, and/or (b) there's reason to believe that an account is the latest incarnation of a user whom we've banned several times in the past. The bar for moderation penalties is a lot lower when we seem to be dealing with a serial abuser.
Edit: I deleted an earlier response to you because I didn't have time to finish it (I wanted to respond to the bit about 'slowbanning'). If I had seen that you'd already responded to it in your parent comment, I wouldn't have deleted it. The original text was:
We've already established that you interpret those comments very differently than I do. The question then would be: is there any way to
I post that sort of moderation comment all the time—tens of thousands of them by now. If the community agreed with you, we'd never hear the end of it; in fact, it would be a bloodbath. So I don't think the community agrees with you.
This is simply not true; you act like you're the only person who's been around here for 15 years. There is simply no mechanism to organize any kind of meaningful pushback. Additionally, by virtue of the fact that you already dismiss the people (like me, with your declarative statements about the nature of my comments) who give you this pushback, it's not clear you'd even notice. Just looking at your history I can see a number of folks who fundamentally disagree with how you give feedback, but I guess to you that's not "valid" pushback?
I only feel safe to give you this pushback in the first place because I know your moderation efforts are ineffective to how I prefer to use HN. Otherwise I'd be afraid of getting actioned against, as you aren't a rational actor when it comes to taking actions against users on HN.
Further, you have this habit of making declarative refutory statements such as these without justification or elaboration. That's pretty much the exact definition of "shallow dismissal".
For example, a "serial abuser" might actually just be someone you disagree with who you then take action against as part of that disagreement, but the way you operate is clearly without that possibility in mind.
Edit: What[0] would[1] you[2] call[3] these[4] comments[5], if[6] not[7] pushback[8][9]? Or do these not count because you dislike these users? I'm quite sure, in your mind, you've dismissed these complaints as invalid, and I think that's an error.
Also no, none of these are me. Also also not for nothing but 'tptacek seems to spend an inordinate amount of time defending your work in the form of replies to complaints, and I personally think that's a massive waste of his time, but c'est la vie...
[0] https://news.ycombinator.com/item?id=32857054
[1] https://news.ycombinator.com/item?id=32831746
[2] https://news.ycombinator.com/item?id=32801256
[3] https://news.ycombinator.com/item?id=32782368
[4] https://news.ycombinator.com/item?id=32777165
[5] https://news.ycombinator.com/item?id=32777628
[6] https://news.ycombinator.com/item?id=32780934
[7] https://news.ycombinator.com/item?id=32773572
I'm not talking about resentful responses from individual users—those are inevitable, if only because misunderstandings are inevitable on the internet, and they don't (necessarily) indicate community discontent. On the contrary, by and large the community downvotes and flags those comments. It's the admins who usually come along and unkill them later.
I'm sure it must be very annoying to be around here for 15 years only to see some random asshole get anointed the big boss of the place and start banning people left and right. But I'm a bit more interested in what people (including you) think I'm doing wrong than you seem to assume.
You’re hiding your behavior behind the mob mentality that punishes dissent, claiming that a shallow dismissal response is valid because the HN mob has attacked with downvotes, so violating your own policies is acceptable.
The fact that I was able to find so many examples in just the past week should concern you. It won’t, because it’s clear you don’t “count” those issues as legitimate, but it should and you should.
“I’m interested in what people think I’m doing wrong.” doesn’t mean you’re interested in improving, however. There are easy, concrete steps you could take; simple rewordings, a policy change or two, that would vastly improve how you interact with the “fringe” of HN.
A tool for sending mails via Mailgun? “Railgun” then, for example.
Banana Cache
Hadouken Security Service
Lightfoot Containers
I mean, this is pretty much the AWS formula.
I'll keep this formula in mind too, and use it when I develop something bigger.
In ten years, none of the original developers of Hotels are with the company. The new generation of engineers is upset both with Hotels’ limitations and the fact that it’s not written in XYZ language which they really want to have on their résumés.
So they embark on a total rewrite of Hotels, and to emphasize the awesomeness, most likely it will be called either Phoenix (because one out of three internal 2.0 rewrite projects is called that) or Venice (because it’s a place that has lots of hotels).
As part of their ambitious rewrite, they also start building a custom message queue in XYZ. It’s called Milan so there’s now a cute city theme. A bunch of other exciting NIH XYZ greenfield projects spring up, all with city code names.
Another ten years go by. A programmer complains to another:
“Where I work is the worst. There’s all these projects written in XYZ which nobody uses any more, and they’re all named after random cities. Why couldn’t they call the hotel booking service something descriptive.”
Descriptive alone does not cut it.
Bonsupoints if your software throws errors, that throw customers. "I want to book a flight to NY, but it keeps saying Venice:DB is full"
Oh, and as for "If it's not that big rename it" - this article is specifically about things that are hard to rename (e.g. public facing APIs or libraries):
> Now, if a name is going to be easily changeable forever, please do make it descriptive.
I disagree with that. Cryptic names can become jargon, and jargon is useful in expert teams. At my last job we had a service whose role was to convert operations from system A to system B so at first we named it systemAOperationsToSystemBOperations. The name was clear but it was a pain in the ass to talk about it. We renamed it adios as a shorter name (irks like a fake acronym of the initial name) and it became way easier to talk and reason about our system. We lose a few minutes once in a while to remind juniors what adios does but we gain an efficient name to discuss the service day to day.