I read a lot into software history, and I can’t really say that there was an era of fantastic naming (even very experienced engineers made some very silly naming) but at least some current was trying to make some sense in the 80s; grep (global regular expression print), awk (Aho, Weinberger, Kernighan; the creators’ initials), sed (stream editor), cat (concatenate), diff (difference). Even when abbreviated, these names were either functional descriptions or systematic derivations. Nobody named the copy command “Sparkle” or the move command “Whisper.”

Early programming languages followed similar logic: FORTRAN (Formula Translation), COBOL (Common Business-Oriented Language), BASIC (Beginner’s All-purpose Symbolic Instruction Code), SQL (Structured Query Language), I believe Lisp stands for list processing. The pattern was clear: names conveyed purpose or origin. Somewhere around the 2010s, a memetic virus infected software engineering. Perhaps it started innocently, developers tired of boring corporate naming conventions wanted personality in their open-source projects? maybe. A few quirky names were charming. A database named after an animal? Sure, MongoDB (from “humongous”) at least has etymological connection to its purpose, even if “Mongo” became the shorthand.

But we didn’t stop there. We kept going. Now we’re drowning in a zoo of meaningless appellations where the connection between name and function has been severed entirely. Probably pattern accelerated with the rise of GitHub and startup culture. Everyone wanted to be the next Google, a meaningless name that became iconic through market dominance. Google could afford to build brand recognition through billions in advertising and becoming a verb. Your MIT-licensed file parser with 45 GitHub stars cannot.

Every obscure name is a transaction cost levied on every developer who encounters it. When you see “libsodium,” you must context-switch from problem-solving mode to detective mode: “What does this do? Let me check the README. Ah, it’s a crypto library. Why is it called sodium? Because chemistry? Because NaCl? Clever, I suppose.” Now, multiply this by dozens of dependencies in a modern project. Each one demands tribute: a few seconds of mental processing to decode the semantic cipher. Those seconds accumulate into minutes and effort, then career-spanning mountains of wasted cognitive effort.

Imagine that you are to explain to a new engineer how is your codebase structured, and the general architecture of some project, and go through the dependencies you use to delegate some certain tasks to and explain how they orchestrate together. Actually let me put my friend’s statement again instead: “We’re using Viper for configuration management, which feeds into Cobra for the CLI, and then Melody handles our WebSocket connections, Casbin manages permissions, all through Asynq for our job queue”.

Now pause and actually process that sentence. there’s a snake, another snake, music, a mysterious proper noun, and… async-with-a-q? Half your mental RAM is busy pattern-matching these arbitrary tokens to their actual functions instead of focusing on the architectural decisions being discussed. This is the equivalent of a cardiologist saying “we’ll install a Butterfly in your Whisper to improve your Thunderbeat” instead of “we’ll place a stent in your artery to improve your cardiac output.” Compare this to reading a scientific paper in materials science. When you encounter “high-entropy alloys” or “shape-memory polymers,” the name itself conveys information. You can make educated guesses about properties and applications before reading a single word of description.

I was told some of the following when I shared my concerns about naming before, here’s my thoughts of some:

• “But memorable names help with marketing!”

  Sure, if you’re building a consumer product. Your HTTP client, cli utility helper, whatever library is not a consumer product. The people who will ever care about it just want to know what it does.

• “Descriptive names are boring!”

  Yes, and surgical instruments are boring. Boring is fine when clarity is paramount. This isn’t creative writing class.

• “It’s just for fun!” Your fun has externalities.

  Every person who encounters your “fun” name pays a small tax. Across the industry, these taxes compound into significant waste And yeah, I know, this is not our biggest concern nor the biggest problem the industry is facing now, but sorry I had to talk about it. .

• “All the good descriptive names are taken!”

  We could have used namespaces, prefixes, or compound terms like every other engineering discipline has done for centuries. We have the technology. But even if you can not do that, at least make the name has anything to do with the product, put a “DB” post-fix, do some word play like how “magit” does. If you couldn’t not be clear, you could have made it relatable at least.

Whatever happened wasn’t malicious—it was cultural. As programming shifted from corporate mainframe work to the community builders. Which was a good thing. , the social norms shifted too.

Thus, we need a cultural correction. Not regulation open source thrives on freedom, but a revival of professional standards through social pressure and education.

Name your library after what it does. Use compound terms. Embrace verbosity if necessary. http-request-validator is infinitely superior to “zephyr” when someone is scanning dependencies at 2 AM debugging a production incident.

If you absolutely must have a cute mascot or reference, fine-make it the project mascot, not the name. PostgreSQL has Slonik the elephant. PostgreSQL is still called PostgreSQL. The elephant doesn’t replace semantic meaning.

Reserve the creative names for end-user products where branding matters. For infrastructure, tools, and libraries, choose clarity. Every time.

The next time you’re about to name your project after your favorite anime character, pause. Ask yourself: “Would a civil engineer name a bridge support system this way?” If the answer is no, choose a better name.

Our field deserves better than a zoo of random nouns masquerading as professional nomenclature. Clarity isn’t boring, it’s respect for your users’ time and cognitive resources.