Software component names should be whimsical and cryptic

The author seems to be talking about names for two totally different things, lumping them under the term &quot;component.&quot;<p>Whimsical project name? No problem.<p>Whimsical type name within a project? Really bad idea.<p>Whimsical variable name? Don&#x27;t even think about it.<p>The concept the author is missing is &quot;convention.&quot; 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.

&gt; See, the scope and purpose of something changes faster than its name can.<p>There&#x27;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&#x27;s scope so much that the name should change, create a new library with a better name instead.<p>p.s. Obviously does not apply to brand names, which need to be distinctive.<p>p.p.s. Rich Hickey talks about this here: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=oyLBGkS5ICk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=oyLBGkS5ICk</a>

Aesthetically, at this point descriptive names almost look unprofessional, or at least quickly made. If you call your thing &quot;ui-state-syncer&quot; I&#x27;m going to suspect it&#x27;s not really a big budget mainstream thing.<p>If it&#x27;s called Vue, I&#x27;m going to think it&#x27;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&#x27;t some minimal internal thing for one specific use case that probably isn&#x27;t mine. I&#x27;ll be more likely to check it out.<p>They also limit the scope of a project. If you have a &quot;datasender&quot; people will say &quot;This shouldn&#x27;t preprocess data! This shouldn&#x27;t compress! This shouldn&#x27;t intelligently decide when to drop frames! It should just send!&quot;<p>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&#x27;t get that feature at all, or you&#x27;ll have to go beyond the name.<p>If you hate features I guess it&#x27;s a good way to make them hard to implement.

Inside this essay giving horrible advice, is more horrible advice:<p>&gt; 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.<p>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.<p>It&#x27;s like a children&#x27;s song ...<p>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<p>And by the end of it you still don&#x27;t know what you are dealing with.

I&#x27;m on the other side of this, as the author is advocating for using code words to compartmentalize infrastructure, which I think creates absurd bureaucratization and incentivises information hoarding, gatekeeping, and a bunch of other organizational antipatterns.<p>Business owners and product managers tolerate the whimsy when systems work, but then suddenly when you can&#x27;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.

I like a middle ground, which is to name things with somewhat-but-not-entirely related names. For example, our authentication service is the Keymaster, the CI service is the Pipeline Worker, etc.<p>That way, they&#x27;re both whimsical but easy to remember, and if they drift a bit, it&#x27;s fine.

Everything in software (and life) is a trade-off and should be balanced and rebalanced. Something we just continuously fail to absorb in our true&#x2F;false programmer brains, since everyone is always looking for those golden laws that always apply.<p>&quot;Always give cute names&quot;, &quot;Always give descriptive names&quot;, &quot;FP is always good, OOP is always bad&quot;, &quot;Always test first&quot;, &quot;Always test later&quot; etc.<p>Golden laws don&#x27;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!)

Think of the new people you hire!<p>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.<p>What is easier to understand at first glance?<p>Picard stopped responding to Luke. Bilbo is also down!<p>or<p>PaymentService stopped responding to UserService. Database-XYZ is down!<p>It might not be exciting but the cognitive load is much lower.

There is a real world example of a complex, critical, domain that has followed this approach religiously for years: prescription drugs. Every prescription drug is given an essentially nonsense non-proprietary (generic) name, with only broad categories identified by a stem (drugs ending in &quot;mab,&quot; e.g., are monoclonal antibodies, those ending in &quot;vir,&quot; are anti-virals). Names that are suggestive of medical target or use, beyond what is implied in the stem, are not allowed. The system is international, with international bodies ultimately approving naming of drugs.<p>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&#x27;t know them well, professionally. And the common drugs - well, let&#x27;s just say, you&#x27;re far more likely to tell someone you&#x27;re on Lipitor (a brand name, for marketing) than &quot;atorvastatin&quot;.

<i>“Descriptive” names don’t create transparency, they create the illusion of transparency.</i><p>...some of the time. The rest of the time they&#x27;re actually very useful. Giving up any attempt at having a descriptive name <i>just in case</i> you get it wrong is throwing the baby out with the bath water.<p>What&#x27;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&#x27;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.

Perhaps just give descriptive names and then change it when the scope changes??<p>&quot;Problem&quot; solved!<p>Afraid of losing stars&#x2F;dlds on the repo&#x2F;etc? Make it clear in the Readme where the new project is. Have warnings et al for NPM projects.<p>Ask npm&#x2F;GitHub to allow name changes with redirects.<p>This proposed &quot;solution&quot; is just bad for many reasons:<p>You need to delve into the Readme to find out what it does. Imagine you&#x27;re seeing a package.json and for each line you have to Google what&#x27;s the project about<p>SEO is best if name matches.<p>These are enough *good* reasons why this advice is a bad idea

Also, unique. Or at least unique-ish.<p>Whoever named the ML thing &quot;transformer&quot; deserves a special place in hell. So many intriguing headlines, so few things worth reading. (I&#x27;m an EE, so I&#x27;m very interested in the <i>other</i> transformers. For some reason, the headlines for these things scan like they could apply to either. Alas, they don&#x27;t.)

I like the distinction between tools and products here.<p>If it&#x27;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.<p>If it&#x27;s mostly a tool, being descriptive is just good SEO. You are not ever becoming a &quot;household name&quot; 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. &quot;Django REST framework&quot; shows up naturally when I google &quot;django rest&quot; and that just benefits both sides.<p>If you are in between the two, opt for the middle: TweetDeck, MailChimp.<p>That&#x27;s my two cents anyways..

I have doubts about the author&#x27;s overall point, but something to consider is how does a name help&#x2F;hinder search? A name that&#x27;s overly mundane, say, &quot;Go&quot;, becomes problematic to google (hence the need to search for &quot;golang&quot; or add other terms).<p>I feel almost like there&#x27;s an analogy between choosing names for packages&#x2F;projects and bird calls. Birds need to make their calls stand out in a given ecosystem. If you have a dozen projects like, say, &quot;object-mapper,&quot; &quot;object-db-mapper,&quot; &quot;object-mapping&quot;, &quot;object-mapper-thingy&quot;, &quot;object-mapping-service&quot;, &quot;db-object-mapper&quot;, it&#x27;s hard to remember wtf was the one you need. If in such an ecosystem your project was named &quot;Orangutan,&quot; it might stand out and be noticed. OTOH, if all projects in a given ecosystem have weird names like &quot;murano&quot;, &quot;swift&quot;, &quot;glance&quot;, &quot;hotdog&quot;, &quot;gorilla&quot;, &quot;zaqar&quot;, &quot;cthulhu&quot;, &quot;funky-chicken&quot;, &quot;Sauron&quot; or whatever, it may be hard to remember what they all do&#x2F;mean -- yes, I&#x27;m giving you the side eye, openstack. In such a space, &quot;cloud-disk&quot; or something might win, IMHO.<p>Slightly tangentially related is the use of odd words in log messages to aid searchability. I&#x27;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.)

I hereby dub this &quot;The Protectiva Paradigm&quot; - an injunction to name things whimsically, not descriptively because a) its fun and b) the function of the thing changes so &quot;give yourself wiggle room&quot;.<p>The name itself comes from Dune, where the Bene Gesseret Missionaria Protectiva is itself whimsical (on some level) and cryptic. <a href="https:&#x2F;&#x2F;dune.fandom.com&#x2F;wiki&#x2F;Missionaria_Protectiva" rel="nofollow">https:&#x2F;&#x2F;dune.fandom.com&#x2F;wiki&#x2F;Missionaria_Protectiva</a>

I strongly agree with this. I’ve worked places that follow both naming styles and I’ve found it’s much easier to get up to speed if the services and repositories have names that don’t overload the language you use to talk about what you’re doing. E.g. if your service that sends out webhooks is called “webhooks”, then newcomers will always be confused about whether you’re talking about the concept or the implementation; if the service is called “voltron”, newcomers might not know what it does initially, but they can discover that pretty quickly.

The throwaway comment about not using diagrams was truly baffling to me.<p>A dashed arrow pointing in one direction is async data flow in that direction, A solid arrow is synchronous, and a swimlane &#x2F; activity diagram shouldn&#x27;t have two-way arrows in it (what would that mean?).<p>How is that more likely to be read wrong than source code? Doesn&#x27;t match my experience at all.

If you want to see this line of thinking taken a bit too far, check out the list of Trilinos packages on github: <a href="https:&#x2F;&#x2F;github.com&#x2F;trilinos&#x2F;Trilinos&#x2F;tree&#x2F;master&#x2F;packages" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;trilinos&#x2F;Trilinos&#x2F;tree&#x2F;master&#x2F;packages</a><p>There&#x27;s ~50, and nearly all of them are incomprehensible. It definitely makes things much less accessible to a newcomer &#x2F; outsider.<p>(Trilinos is a set of scientific &#x2F; engineering libraries for HPC)

If you went down the hell hole of microservices please do give descriptive names to services.

I think software component names should all just be UUIDs.<p>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).<p>There is also much less risk of collisions. In addition, you don’t waste any time trying to come up with a name.

If your functionality breaks the description, rename the software, or outsource the new functionality into a plugin or a new software. Pure Cryptic names are just cancer, even more than software which has grown out of its descriptive naming.

Another reason is that people will _care_ about Shelob. It builds a community. They wouldn&#x27;t care about an InternalWebCrawler.

There is this one man. He is great at marketing, and he once summed it up in just two sentences, but it&#x27;s because he is so shockingly vain, vapid, and shallow that he is a genius at this art.<p>&quot;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.&quot;<p>I am not going to tell you who this is, but the point stands.<p>The name should be easy to pronounce, it should zing, and your <i>first reaction</i> should be positive. Why do you have it? Doesn&#x27;t matter. It&#x27;s either there or it&#x27;s not.<p>A good name is at least half of a product&#x27;s success.

If i see the words &quot;whimsical&quot;, &quot;delightful&quot; or {insert emoji} on a project readme, I will instantly dismiss that project. I&#x27;ve learnt not to trust such projects.

Naming things is hard. I still get it wrong after a decade+ of building complex systems.<p>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.<p>If you aren&#x27;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&#x27;ve got a shitload of odds and ends in static classes simply named things like &quot;Utility&quot; and &quot;Hack&quot;. When you aren&#x27;t so invested in what something is called, I have found you are much more willing to get &quot;creative&quot; with it. Naming things can also start to imply some sort of structure, so keeping it flat like this helps reduce the cognitive load.<p>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 &quot;beneficial&quot; owner and a &quot;beneficiary&quot;. Applying reductive&#x2F;creative naming schemes to this domain would likely cause more harm than good.<p>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 =&gt; Meta).

In our stock trading algorithm, a parent order could have multiple child orders. If the parent order quantity was amended down, it might be necessary to cancel some of the child orders. The function name for this was called getSophiesChoice()

Krazam Microservices <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y8OnoxKotPQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y8OnoxKotPQ</a><p>I work on the same, but never learnt to use non-descriptive names.

OK, I guess I&#x27;ll have to argue against. Please don&#x27;t make component names whimsical. Your idea of whimsy and fun is potentially confusing or (worst case) offensive to others. Yes, make them unique and searchable. Yes, make them memorable and pronounceable. Yes, make them SFW.<p>It would get tiring to have to keep explaining to new team members that our prime number generator is named &quot;optimus&quot; even if it was initially clever.<p>I don&#x27;t look forward to convincing my boss we need to pull in &quot;libAnimeBabe&quot; as a dependency even if it&#x27;s the best parser for a file format we need to import.<p>Nobody wants to find out a year after all of our marketing material is put together that our software name means &quot;asshole&quot; in another language.<p>Don&#x27;t make me have to pronounce an unpronounceable Gaelic word every time I do a presentation on our software stack because you&#x27;re Irish and just had to name your component that way.<p>There are lots of ways &quot;whimsical&quot; can backfire unintentionally. Save your creativity for the actual software solution.

This is the absolute antithesis to how I operate and I disagree almost to the point of being offended.<p>Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects&#x2F;services as they want, and organize everything based on whim. You get this: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y8OnoxKotPQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y8OnoxKotPQ</a><p>For me that is not a parody, it&#x27;s lived experience.<p>&gt; 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.<p>When what a thing does changes <i>then the name should also change</i>. 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 don’t care if you name them descriptively or weirdly, just please name them distinctly so when I have to do searches for them I come up with the right thing. The worst is Apple’s “Pages” and “Numbers”. Try doing a search for how to do something in either of these products. These are far from the only examples.

&gt; Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is.<p>I&#x27;ll never understand this mentality, where a silly project name is a source of &quot;fun.&quot; I would never dare tell anyone what should be fun for them... except in this case, where I <i>will</i> say that funny names are not actually fun.<p>I can only imagine working in the author&#x27;s ideal company:<p>&quot;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?&quot;

As someone who&#x27;s working on a project right now that&#x27;s full of whimsical&#x2F;cryptic names (project is called Sandman, modules within the project include Mystic, Hypnos, Lethe, Morpheus, Dreamer, and Lucid), this was validating to read. That said, if my project was anything more than a solo personal project, I&#x27;d only keep the Sandman top-level name and rename the modules to things like Parser, Server, Client, etc. to make them more maintainable by others. I keep them because I&#x27;m the only one working on the project and I quite enjoy the sense of Hollywood-hacker-montage they impart me when I&#x27;m debugging.

I larelt agree. I wrote a while back about how to make good names[1]<p>Choosing whimsical names is a pretty good way to satisfy my two most important requirements. They are often unique and don&#x27;t mislead people.<p>Of course my ideal name would also give some hint about what it does (I think Google&#x27;s BigTable may be one of the best named products) but I think this is far less important than the other two requirements.<p>[1] <a href="https:&#x2F;&#x2F;kevincox.ca&#x2F;2021&#x2F;03&#x2F;23&#x2F;good-names&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kevincox.ca&#x2F;2021&#x2F;03&#x2F;23&#x2F;good-names&#x2F;</a>

I agree with the author but for different reasons.<p>Software should be fun! I love it when packages have goofy names. If I can shitpost with the language I&#x27;m going to get just a little more invested in it.<p>And to be honest, even the &#x27;serious&#x27; names fail at connoting respectability to begin with. Your grandpa would get annoyed just hearing the word &#x27;containerisation&#x27; - 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?

Had a thing where the function that gave the user activation feedback was called &quot;SparklePonies&quot;. Others found that confusing, especially people whose first language was not English.

Actually agree.<p>When I think of programming things I use the most, most of them have whimsical names that mean nothing.<p>I mean, say, “grep” means… something with regular expressions I guess? But nobody cares. It’s just “grep”.

This is bullshit. I don&#x27;t want dopamine hits. I want money for my code. And guess what increases the money I get from my code? Naming stuff consistently with their meaning.

Strong &quot;Death of Perosnality&quot;[1] vibes here! That was about ux, this is more about dx. In that thread I advocated pretty heavily for apps not being special[2], for their best service usually being to get out of the way, to be slim &amp; light, focused less on initial charm &amp; more on enduring usability.<p>I think most of that applies here. The whimsy &amp; fun is cute at first, but it&#x27;s rarely long term magic. For new teams &amp; outsiders, it&#x27;s a pain. I&#x27;ve had to work eith a sync engine where there&#x27;s 20 subsystems seemingly each named by randomly picking a name from Encyclopedia of Mythology. There&#x27;s probably something cute &amp; creative &amp; whimsical to the authors, but as someone trying to use the thing, it&#x27;s merciless &amp; oppressive, a huge turn off.<p>[1] <a href="https:&#x2F;&#x2F;tdarb.org&#x2F;blog&#x2F;death-of-personality.html" rel="nofollow">https:&#x2F;&#x2F;tdarb.org&#x2F;blog&#x2F;death-of-personality.html</a> <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32777411" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32777411</a> (79pts, 3d agi, 63 comments)<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32791861" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32791861</a>

For an external&#x2F;public project? Sure! For a release code name (like Debian does), yeah why not. For internal service names? No. Not unless there&#x27;s an obvious connection to its role (ie: TrafficCop handles DOS attempts, etc)<p>I&#x27;m working with some legacy code that followed this pattern for internal services. It&#x27;s a nightmare. WTF is Bilbo, oh it handles 2fa? And what&#x27;s Pippin again? And there&#x27;s a dozen other examples, of course most of them are from LOTR. I literally have to maintain a mental mapping because there&#x27;s no rhyme or reason to the choices.<p>That&#x27;s actively anti-developer, anti empathy and I hate it. It&#x27;s not cute, fun, helpful, professional. I can&#x27;t think of a single redeeming quality. Maybe it&#x27;s ok for a prototype you intend to throw away because it&#x27;s so ridiculous you don&#x27;t want to use that name with your boss, so it encourages non attachment.<p>If you really can&#x27;t pin down a name that describes the thing you&#x27;re making, maybe you don&#x27;t know what you&#x27;re making?<p>Also, we can rename and&#x2F;or retractor things. And we should if their responsibilities change!<p>Edit: added distinction about internal vs external.

I work at a company where all of our services have stupid Greek code names. It adds a layer of obscurity, increases the cost of onboarding devs and context switching, etc. It&#x27;s a goddamn stupid idea.<p>The author here is equivocating opaque code names with multi-use repos. They&#x27;re saying &quot;see!? some repos on github do things in addition to their literal name.&quot;<p>That has nothing to do with the fact that obscure code names are a stupid anti-pattern.

I very often whip out this tried by true joke. People often think it&#x27;s &quot;just a joke&quot;, but I actually think of it more as an adage, as words of wisdom, that also just happen to be whimsical.<p><pre><code> There are only 2 difficult things in computer science: 1. Naming things 2. Cache Invalidation 3. Off by one errors</code></pre>

A handful of examples don&#x27;t prove anything. If a Widget Lookup Service is used to lookup widgets for its entire lifespan, calling it Frodo isn&#x27;t doing anyone any favours.<p>And it&#x27;s not like &quot;oops some gadget polishing code fell into my widget lookup service&quot;: don&#x27;t put inappropriate crap into your solution. Little discipline goes a long way.

This reminds me of a &quot;problem&quot; we had in a code base that we maintained. It was a test framework written (and I use the term loosely) in perl. Someone wrote a throwaway script which later grew like a mould into a &quot;tool&quot; that was used by a large business group. None of the maintainers (including myself) knew perl properly. Of the 8k odd lines, 5k was a single function descriptively called `run`.<p>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 don’t think you need to go full startup when naming stuff, but you also don’t have to go full bureaucrat either.<p>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:<p>RocketPack: package manager<p>DataBank: caching auto loader<p>Murphy: automated testing<p>Each of those modules is named quite specifically but that’s because they do one thing.<p>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.<p>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.<p>But I don’t think calling them all after my favourite Futurama characters would have been a better choice.

&quot;Descriptive&quot; names like in the article might not be a good fit, because they&#x27;re just badly chosen and sometimes lie to you.<p>I&#x27;d argue that actually descriptive names aren&#x27;t the worst thing ever, I wouldn&#x27;t mind seeing a project&#x2F;source code repo named &quot;Client Bill PDF Generator&quot; as long as the name on the tin actually matches what&#x27;s inside of it. Of course, that implies that in the case of scope creep you should be able to change it as necessary.<p>What this avoids is the problem of not needing a glossary to figure out what &quot;Shelob&quot; 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: &quot;Shelob: Client Bill PDF Generator&quot;.<p>It&#x27;s kind of how I approach naming my homelab servers&#x2F;saving SSH sessions, a randomly chosen hostname comes first, but what it actually does is appended to the connection name&#x2F;monitoring dashboard name - mostly because what I use the servers for might change so often, that this is one of the use cases where &quot;fun&quot; names make sense.<p>Actually, Dylan Beattie once described why &quot;fun&quot; names might make sense, in a conference talk called &quot;Life, Liberty and the Pursuit of APIness : The Secret to Happy Code&quot;, though it also touched upon other aspects of development.<p>Here&#x27;s the video timestamp for the problem situation: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;BIkXid_pBiY?t=769" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;BIkXid_pBiY?t=769</a><p>Here&#x27;s the video timestamp for the proposed solution: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;BIkXid_pBiY?t=946" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;BIkXid_pBiY?t=946</a><p>The argument went along the lines of &quot;by giving it a name, you cut out a lot of the noise&quot;. Curious, I can kind of understand that point of view, even though I&#x27;m not inclined to fully agree with it.

I came up with the idea with my first PC to name my computers after Popes (skipping the numbers). That computer was named Peter. To be honest, I could not tell you the name of the laptop I’m typing this on right now without looking it up. So much for a clever naming scheme being useful.

Cryptic names will only have one outcome. The &#x27;ingroup&#x27; whom understand the network of names will run the show and anyone who asks what AlphaBetaCharlie actually does, is at an eternal disadvantage.<p>Judging descriptive names by their worst examples is not exactly a charitable interpretation.

Also an interesting question for company names. Google, Amazon, Apple are whimsical and cryptic. Microsoft hints at software, but is still not very descriptive. Facebook was descriptive, but they switched to Meta, probably to have a less constraining name.

Can&#x27;t have a post like this without a mention of this tweet:<p><a href="https:&#x2F;&#x2F;twitter.com&#x2F;codinghorror&#x2F;status&#x2F;506010907021828096" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;codinghorror&#x2F;status&#x2F;506010907021828096</a>

I work in web, and one guy did this for two modules in a non-critical server, just TWO before I flat out told him to stop. &quot;What does X mean&quot; was a common question across people who had actually seen the code before and forgotten, and it was absolutely the first question someone trying to learn the codebase asked. It was a frustrating and silly practice that added to cognitive load and corroded faith in the authors decision-making.<p>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.

I don’t understand why it’s seen as a given that component names can’t be changed. All the given examples are public project names, where there’s a point to be made. For internal components though, where are your refactoring tools?

I give mine “whimsical” names that have alphabetic first letters, and may correspond to positions in a hierarchy.<p>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 &quot;CHAMELEON&#x2F;COBRA&quot; (They are basically at the same logical layer).<p>[0] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;forensic-design-documentation&#x2F;#badger" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;forensic-design-docu...</a>

I&#x27;ve gone back and forth on this.<p>I think if you expect you&#x27;ll only need a small group of people to know the name (the &quot;Shelob&quot; example at a startup), or you expect a large group but only are adding one name to learn (&quot;Vue&quot;), it&#x27;s fine.<p>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.

I am on the exact opposite side on this. I always name things after exactly what they do, and I&#x27;ve never had an issue with one of my components taking on a role it wasn&#x27;t intended for. If the scope changes, that component probably gets wrapped, or replaced, or somehow else room is made for a new properly named component or tool.<p>This is something I am very grateful for when I return to a project after some time away and the code is documenting itself.<p>But I&#x27;m also a fan of disposable code. If I&#x27;m actively working on something I probably rewrite more or less the whole project every 18 months bit by bit.

Mysql_real_escape_string was a fun one years back for PHP.<p>The original escape turned out to have character issues or so, so they made a new one: mysql_real_escape_string<p>We were hoping they would find another issue and release a mysql_real_real_escape_string

Here&#x27;s my rules: if you&#x27;re writing an API layer for your CustomerTransactions service then name it descriptively. If you&#x27;re creating a tool to be wielded, name it creatively.<p>If your software is a &quot;final product&quot; which by definition can grow in requirements then it&#x27;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&#x27;m glad we didn&#x27;t call a hammer a NailPounder since it can do so much more.

Naming is hard. It requires an understanding of what a thing does (or more accurately, at the time of coming up with the name: what the thing WILL do).<p>One useful practice I&#x27;ve acquired over the years is to make the names unique. It makes it easier to search for them later.<p>Generally, I would lean towards descriptive names. If the name no longer fits the thing, that&#x27;s a great warning about scope issues. If it sounds &quot;weird&quot; for other named things to be dependent on or be required by the named thing -- that&#x27;s often a hint about a context issue.

I remember trying to fix Katello once and trying to figure out why &quot;candlepin&quot; was broken because it couldn&#x27;t talk to &quot;gutterball&quot;. Everything about the situation was terrible.

You could always take the approach of JRR Tolkien: come up with the name first, then try to figure out what the software will do from that name. In a hole in a database, there lived a hobbit.

Next he&#x27;s going to tell us the proper way to do cache invalidation.

The biggest issue, I see with learning how software works, is common names.<p>For example, game engine. Some library or framework, that helps you to build games. Nice.<p>But what they do for you in detail isn&#x27;t known, and can take months to understand.<p>Unity does much more than Phaser. Angular is a total different beast than React.<p>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.

This satirical video about microservices shows just how deep whimsical project names (and microservice architectures) can go. Displaying the user’s birthdate starts with BINGO (the service that knows everyone’s name-o) and ends with GALACTUS (the all-knowing user service provider aggregator) talking to EKS (Entropy Khaos Service), soon to be EOL’d by OMEGA STAR.<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;y8OnoxKotPQ" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;y8OnoxKotPQ</a>

I do like the Intel code names like Tiger Lake, Light Peak and Ivy Ridge. They evoke some kind of combination of Manhattan project megaproject and just-charted territory.

Like this? <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y8OnoxKotPQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=y8OnoxKotPQ</a> :D

I can just about tolerate this for brand names, as there&#x27;s an additional set of requirements there, but for everything else, it&#x27;s just gatekeeping and unnecessary obfuscation. If the purpose of something changes, fork it off into something new or just rename it if possible. Apache TinkerPop Gremlin might be fun for the creators, but not for anyone trying to understand what it does.

Please don&#x27;t.<p>My team work on a project with many &quot;funny&quot; names, including but not limited to, liboyster, libowl, several characters from Fort Boyard (<a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Fort_Boyard_(game_show)" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Fort_Boyard_(game_show)</a>, patric the starfish....<p>It was awful to work with, please don&#x27;t go that.

In general, disagree. And often the deep track names that are assigned in lieu of descriptive ones box out people that don’t share cultural touchpoints. <a href="https:&#x2F;&#x2F;twitter.com&#x2F;staysaasy&#x2F;status&#x2F;1419274984459997186?s=20&amp;t=Eg4YVzglF8CYL-iRgpD-vw" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;staysaasy&#x2F;status&#x2F;1419274984459997186?s=2...</a>

I called my startup <a href="https:&#x2F;&#x2F;text-generator.io" rel="nofollow">https:&#x2F;&#x2F;text-generator.io</a> despite the name ... it uses image recognition to help generate text and offers an embeddings API, trying to extend it now to generate other forms of content (images, audio etc) depending on the input which is unfortunate

The author subjected themselves to confirmation bias by specifically searching for “despite the name”. Perhaps for every service that outgrew its descriptive name, there were 99 that helped people understand them more easily.<p>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.

What I take from this that across languages, we ought perhaps to have the option, now and then, to use names have two parts: blotwort.django_lint for example. The whimsical part is permanent, the descriptive part is ignored when compiled (has no semantic force) and can be changed as needed without altering how the program executes.

I couldn&#x27;t disagree more. In my opinion the golden rules of naming things are:<p>1. Names must be descriptive.<p>2. Names must be unambiguous.<p>3. Names should be no longer than they need to be to achieve #1 and #2.<p>If your names are becoming less descriptive over time it&#x27;s because you&#x27;re not writing well. It&#x27;s not easy to write well, but that&#x27;s the job.

I recommend this book, it was written by top people with decades of experience in creating runtime, OSes, base class libraries, designing APIs, naming and so on<p>Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Addison-Wesley Microsoft Technology Series) 3rd Edition

My favourite example of how this can go sideways is BlueJeans - video conferencing software.<p>There&#x27;s probably some cultural context I&#x27;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.<p>That was 9 years ago and I still don&#x27;t know BTW.

Naming things is hard.<p>I agree that bad and&#x2F;or misleading names are, well, bad. However, I don&#x27;t agree that we should just give up and name everything {SomeCrypticNameIThinkIsCool}.<p>Invest time in naming things well the first time.<p>Invest time in renaming things to be more accurate when it is feasible.

I love writing libs and giving them unconventional names. See Khadijah a go struct to Cypher cRUD query generator <a href="https:&#x2F;&#x2F;github.com&#x2F;emehrkay&#x2F;khadijah" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;emehrkay&#x2F;khadijah</a>

&gt; CO_Cron: Despite the name, uses node-schedule rather than cron.<p>That seems like a bad example. I&#x27;ve often googled &quot;cronjob foo&quot; for how to schedule something in foo. Seems like &quot;cronjob&quot; is a general term for scheduling now.

Even in the planning phase, when you have a new project, giving it a name helps in general conversation. It also gives it an exciting mystique and makes it seem like you still give a shit about the job.

are we talking about project names or the names of classes and objects?<p>if it&#x27;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&#x27;s ok. no one will care if gutenberg also handles analytics callbacks or whatever.<p>classes really shouldn&#x27;t change in scope, ideally, so it&#x27;s probably better to be a bit more specific to their purpose.<p>overall this is a good hot take, if a bit broadly put.

One company in particular I worked for had exotic cute meme names for every big service in our service architecture. Sometimes conceptually related to what it did but often not. Damn annoying!

<a href="https:&#x2F;&#x2F;www.dropbox.com&#x2F;s&#x2F;amoz52ja8got5wq&#x2F;navigation.png?dl=0" rel="nofollow">https:&#x2F;&#x2F;www.dropbox.com&#x2F;s&#x2F;amoz52ja8got5wq&#x2F;navigation.png?dl=...</a><p>:D

I couldn’t help but think about this video <a href="https:&#x2F;&#x2F;youtu.be&#x2F;y8OnoxKotPQ" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;y8OnoxKotPQ</a> while I read this.

&gt; “Don’t Be Cute<p>&gt; 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().<p>&gt; Say what you mean. Mean what you say.”<p>~~ Clean code, Uncle Bob

Stop with the cute cryptic names. If you want descriptive names that can be said with one word consider a good acronym, otherwise just say the whole name.

In functional programming most variable names are single letters, except for function names, they are either name of spices or animal parts.

I&#x27;d be curious to hear thoughts from anyone with practical experience of urbit, considering their intentionally nonsensical naming choices.

Radical idea: If the usage&#x2F;purpose of something diverges significantly from its original name, change the name.

Is this written by the same &quot;Histocrat&quot; as the channel on youtube that posts short history lectures?

I&#x27;m old. I prefer a name that hints at the usefulness of a project.<p>Now get off my lawn!

What an awful article. I wish I can downvote

I&#x27;m iffy on this for software (because you can always spin up a separate descriptively-named library to house the &quot;scope creep&quot;), but I&#x27;m 100% about this for team names at software companies, for the exact same reason: because you _can&#x27;t_ easily &quot;spin up&quot; another team to handle the inevitable scope creep.<p>Let&#x27;s face it, no software company where any of us work has ever been satisfied with &quot;well, we have enough features already, no need to build more.&quot; The incentives _always_ push for-profit software towards &quot;build a shiny new feature&quot;, because you can&#x27;t upsell existing customers the same features they already pay for, but you _can_ upsell them _new_ features.<p>So companies monotonically grow their featureset.<p>Companies also do _not_ monotonically grow their employee base, and _certainly_ not at the same rate as they grow their featureset.<p>So, for example, the &quot;email send team&quot; of today will probably become &quot;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&quot; team before long. And they&#x27;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&#x27;ll still regularly have to deal with).<p>In the meantime, those &quot;some-but-not-all&quot; categories will be shared with other teams, usually in a way that&#x27;s not neatly describable in 1-2 words.<p>So do you keep constantly changing your &quot;descriptive&quot; team names and fleshing them out into entire often-mutating paragraphs so that they&#x27;re _actually_ descriptive? Because you&#x27;re _certainly_ not going to wait to build a feature until there&#x27;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&#x27;s name again?<p>Or do you accept that memorable-and-unique-but-not-descriptive team names like &quot;Apollo&quot; or &quot;Wombat&quot; are a better use of your time, and find other ways (like relating per-feature PagerDuty &quot;services&quot; to team-level escalation policies) to map &quot;feature X is currently owned by team Y&quot;?<p>Because honestly? 70% of the time that you would want a &quot;descriptive name&quot; for a team, it&#x27;s because you&#x27;re trying to reach&#x2F;page the right team to fix a problem.<p>Set up feature&#x2F;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&#x2F;reparented later.<p>To put it in programmer-friendly terms, don&#x27;t use magic strings, factor out real identifier constants, and reference that constant instead of duplicating it.<p>P.S. to those of you who might say &quot;you can just pick a generally-descriptive-enough name without it listing every feature&quot;, I once worked on a team named &quot;&lt;Product&gt; Email Team,&quot; and we _frequently_ got questions&#x2F;tickets&#x2F;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 &quot;downstream&quot; thing). We also sometimes _didn&#x27;t_ get questions passed our way that were related to the non-email features we&#x27;d accumulated over time (see also: featureset growth speed vs. &quot;headcount&quot; growth speed). We were eventually renamed &quot;&lt;Product&gt; Email And Content Services Team&quot;, ironically because our existing &quot;descriptive&quot; name was deemed &quot;insufficiently descriptive&quot;. Rather than fixing the problem, the new name in fact only exacerbates the problem, since no two people can clearly agree on what &quot;Content Services&quot; are.

Urbit devs agree 101%

Also variables.

naming a project != naming a variable

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that&#x27;s as hard as the world gets.<p>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.<p>1. You&#x27;re a relatively junior engineer who has gotten used to thinking about productivity as slamming code that tweaks existing systems into new incremental features<p>2. You work on some fucking web service.<p>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 &#x2F; 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_.<p>I know I&#x27;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.

This is terrible advice. Cryptic names are horrible. It&#x27;s a layer of cognitive overhead that no one needs. Yes if it gets so big that it&#x27;s out grown it&#x27;s original purpose that&#x27;s a problem. But if it&#x27;s really big people know what it is because it&#x27;s big. If it&#x27;s not that big rename it!