FUBAR: Stop Using Acronyms and Put Some Thought Into Names 💥

How you do anything is how you do everything. And that includes how you name things.

In software, communication isn’t just nice to have—it’s essential. Every label, name, or term we use becomes part of the developer experience. And too often, we make that experience worse by being careless, cryptic, or too clever for our own good.

Let’s talk about acronyms, bad naming, and buzzwords—and why they’re quietly sabotaging your team.

🚫 Acronyms Aren’t Helping

They’re supposed to simplify things. But most of the time, they just make things harder.

• A different language: Acronyms feel like insider speak. New hires, cross-functional teammates, and even your future self will have to pause and decode.
• Not inclusive: If someone has to ask what it means, you’ve already created a barrier.
• Pretentious: It can come off like you're trying too hard to sound smart—or worse, important.
• Meaningless over time: The more you use it, the less anyone remembers what it stands for.
• There’s usually a better name: Just say what it is.
• Cool for the sake of being cool: If your acronym feels more like a brand than a descriptor, you’re doing marketing, not communicating.

🤦 Poor Naming is a Long-Term Tax

Every name you pick is a design decision. Treat it like one.

• Words matter: Labels shape how people understand and relate to a thing.
• You’ll regret rushing: It always seems minor… until you’re stuck explaining it for the 50th time.
• Don’t overthink it, but don’t ignore it: No need to spiral, but don’t shrug it off either.
• The more important, the more care it deserves: Core services, shared concepts, major features—these names stick. Make them count.
• In code, naming is UX: Good naming makes code readable, teachable, and usable.

One time I translated a system that labeled every interaction as a “digital retail finance transaction” into what it really was: a loan. The sighs of relief were audible. That’s the power of naming something what it is.

🎭 Branding and Codenames: Fun but Fragile

Cute names are fine… until people have no idea what you’re talking about.

• Fun ≠ Functional: Internal names like “Magical Unicorns”, "Percolator" or “Storrow Drive” don’t tell you what the thing does.
• Don’t leak into code: Keep branded terms in your marketing docs, not your logic files.
• Name it for association: The name should naturally connect to its purpose. Don’t force it.
• Great for pitch decks, bad for PR reviews: What sells well doesn’t always read well in a pull request.

📣 Buzzwords Make Things Worse

Buzzwords try to make things sound big and cool. Usually, they just make them vague and bloated.

• Simple things sound complex: “Synergizing omnichannel architecture” vs. “Hooking up the API.”
• Trendy ≠ clear: If you’re aiming for clarity, skip the hype.
• They age fast: Buzzwords go stale quick. Good naming lasts.
• They're red flags: When someone can’t explain a project without buzzwords, they might not understand it either.

✨ Slangcronyms? Use with Care

Not all shorthand is bad—just know where and when to use it.

• Great for Slack and casual chats: Slangcronyms like FUBAR or YOLO can bring levity and bonding.
• Terrible for docs: If someone needs to reference it later, it shouldn’t require translation.
• Sometimes a great icebreaker: Used right, they can set tone and build camaraderie—as long as you're not relying on them to explain the work.

🧠 Final Thought

Naming is part of the job. If you care about the experience of working in your codebase or your team, then you have to care about the language you use.

So don’t fall for the trap of sounding cool, clever, or corporate. Be clear. Be honest. Say what the thing is. Give it a name that respects the people who’ll have to use, support, or explain it for years to come.

Because how you name things… is how you build things.