Technical writing in a specific subject domain often suffers from poor readability. Abbreviations harm readability, along with other problems, because they introduce ambiguity outside closed audience groups who share a common domain language.
You need a plan for abbreviations that accounts for your audience. If you like modelling then, as part of this plan, you may want to model different kinds of abbreviations. And while you might know the difference between an initialism and an acronym, you might miss the more important distinction between jargon and laziness.
* if you pronounce it pock
Acronyms, initialisms, and other abbreviations
An initialism abbreviates a phrase with its initial letters, which you pronounce as individual letters, such as PM for product manager. An acronym also abbreviates a phrase with its initial letters, but you pronounce it as a single word, especially for acronyms like SWOT (strengths, weaknesses, opportunities and threats) that have the same spelling as a word.
Abbreviations also include contractions, which shorten one or more words by omitting letters, as in etc. for et cetera, and don’t for do not. Unfortunately, these categorisations don’t help with writing and written style guides. In good writing, avoid lazy abbreviations.
Don’t use lazy abbreviations in writing
Some abbreviations provide a shorthand in writing or speaking, to save typing or syllables. Something like PM works well enough in a spoken context, when you know this won’t cause any product manager vs project manager confusion among your current audience. Writing, however, reaches other people at other times, and leads to ambiguity.
Don’t use lazy abbreviations in writing. Write product manager out in full, to make your writing easier and faster to read. It doesn’t matter what you write in notes that no-one else will read. But as soon as you write for other people, prioritising the reader improves your writing.
Definitely don’t make up your own abbreviations, which non-native English speakers can’t even look up in a dictionary. When new abbreviations do appear, that happens in a group context, resulting in shared jargon.
Don’t expand jargon abbreviations
An initialism like URL works differently to lazy abbreviations. If you don’t know what URL means, then you probably don’t know what Uniform Resource Locator means either. Similarly, when explanation of URLs mentions HTTP resources, if you don’t know what HTTP means, expanding that to Hypertext Transfer Protocol probably doesn’t help.
MVP has the same kind of problem. You don’t resolve an argument about what qualifies as an MVP by explaining the terms minimum, viable and product. Eric Ries wrote a whole book about the concept, and people still argue about it.
Some abbreviations and their expansions both belong to the same jargon. Within their domain, expanding them doesn’t add any clarity, while readers outside the domain need explanations instead of expansion. Instead of digressing into an explanation of HTTP resources, you could describe a URL as the unique address for a web site, or other Internet resource, or a web site’s unique address, depending on the context.