Don't abbreviate
Abbreviations are ambiguous. If you’ve used abbreviations, chances are that you’ve been asked what that means. You can remove that ambiguity. The best way is to spell it out every time.
And if you're thinking that "if someone has to suck it up, it should be the audience", that the audience should learn it in the first place, then hopefully, by the end of this post you would be convinced otherwise.
The problem of abbreviations is similar to letting people off before you board public transport. There is a correct way of doing it. You first have to create room inside a confined space or you risk tangling everyone up.
Likewise, to share the meaning of an abbreviation among a group of people, you must explain it at least once. However, we can't expect those who abuse them to do that. By definition, they use them in the wild without setting the context. And they might actually not know the expanded form of the abbreviation!
So, keep it simple, don’t use abbreviations in the first place. Everyone will know what you're talking about, even yourself.
Now, why is it such a big deal? Every time I come across an unfamiliar abbreviation, I lose my train of thought.
How many times how you been frustrated by a reading and stopped it midway because the understanding was fading?
This is even more challenging during discussions, and the difficulty multiplies in a group. For example, while I'm trying to make sense of the abbreviation I might miss out on parts of the conversation, leaving me in a position to merely follow rather than participate.
And this applies to any new member that is not aware of the context. If the abbreviation is ambiguous, however short the interruption, it still breaks the flow.
Breaking flow and missing on valuable feedback from e.g. your team mates is worse than spelling out the abbreviation every single time.
In fact, spelling out the abbreviation every single time is a fixed cost that only one person has to pay. While understanding the abbreviation is a cost that everyone has to pay at least once. Plus, the cost of losing the flow and valuable feedback is virtually unbounded, and can even affect future audiences.
Moreover, the speaker herself can be affected as others might interrupt asking for clarifications.
So, creating context is key, but rarely worth the time, effort and risk of interruptions than always defaulting to spelling it out. It's a simpler rule to follow than managing exceptions.
And exceptions exist but way too often they become the rule, so again, don't abbreviate, unless you really care about others, in which case I trust you'll do the right thing.
To use abbreviations correctly, you must know your audience. WTF does that mean? It means that I am very confident that any English speaker that is still reading this post is literate enough to know the meaning of WTF.
But no matter how grounded your assumptions are, you are one and the audience is possibly in the billions. Understand the trade-off.
If you're writing, introduce the abbreviation with a Clear Explanation (CA) that disambiguates the meaning of the CA. Now you know we’re not talking about the state of California.
Technical contexts use this approach a lot. Try reading any random paper on Large Language Models (LLM) on arxiv.org and you'll be greeted with a handful of abbreviations.
Sometimes the implied meaning of an abbreviation is more easily understood than its expanded form. In those cases, the abbreviation accomplishes it's objective in transferring the implied meaning more effectively than the expanded form.
For example, take CRM - Customer Relationship Management. In a tooling context it's often intended as workflows on top of your contact list than the specific management of customers. To add to that, think of a contact list of suppliers. Should you now refer to a Supplier Relationship Management (SRM) and leave everyone else wondering how that differs from a CRM?
Therefore, given the right context, a speaker who cares, abbreviations can be used. However, the mechanics of abbreviations are stacked against clarity and people tend to be lazy.
And be lazy by all means, learn one simple rule, don't abbreviate. Achieve clearer communication, don't miss out on interactions. Don't break the flow.
Examples
- Good and bad from Out-of-memory victim selection with BPF:
This problem is still clearly not solved to everybody's satisfaction, though, so it was only a matter of time before somebody introduced a way to select the out-of-memory (OOM) victim using BPF.
Can't quite wrap my head around why OOM is properly introduced but not BPF. Sure, the technical context, the target audience, the title all point to the fact that BPF should be well understood. But WTF! I had to google that. I landed on the newsletter through Hack News, so the target audience can be wider than intended. If you're still wondering what BPF is, share my pain, go google it (in fact I might need to do that again).
- Bad abbreviation from Leaving Haskell behind
The absolute biggest pull for me, when first coming to Haskell, wasn't monads or DSLs or even types.
So, while I know that a DSL is a Domain Specific Language, it did not feel right in this context. So I kept wondering what the author meant. I thought every other mention is a Haskell feature-level strength. A DSL is a language itself so did not resound with that meaning. I then understood that it meant ease of embedding a DSL.