I hereby announce my new four part series: AFS (Acronym Fatigue Series), where I will explore my acronym aversion for my readers enjoyment:
In part this is because acronyms are a way of in-group signalling. On the one hand if you find an unknown acronym in the wild, you are left lost until you find a definition elsewere. But if you understand them, you are left with a sense of feeling as part of the group. This is exploited in tech marketing as a way to signal they are part of the group, and it works! I don’t blame them. In a previous job, marketing spammed so many Cyber intelligence and Cybersecurity acronyms that I doubt any engineering individual contributor in the company was able to define them all. Every new Epic brought its new family of acronyms, some even invented inhouse.
I think this makes some sense, particularly from a marketing (or HR/recruiting) standpoint, but from an engineering perspective I think this ties back to a deep-seated desire for efficiency coupled with a common lack of concern for taking the perspective of the out-group. Engineers would much rather write less to the get across the same point and assume this efficiency will be appreciated by the reader, rather than a barrier to comprehension for anyone that doesn't know what the acronym refers to.
When combined with a (normally good) industry trend towards descriptive product names rather than creative/inventive, products will large technical sway are frequently abbreviated. AWS SQS is a much quicker way to communicate your technical design than Amazon Web Services Simple Queue Service.
The best teams/organizations maintain an internal dictionary of terms used so it's easy to understand the internal conversation. Maintain is doing a lot of work in that sentence - a badly kept or out-of-date dictionary can be worse than useless.
And it goes without saying that everyone should make much broader use of the tag than they currently do.