There's an old joke about programming:
There are two hard problems in programming: naming things, cache invalidation, and off-by-one errors!
Naming things is the hardest problem in programming.
Jargon is a required aspect of any technical communication. Don't believe those who claim otherwise. Musk rails against acronyms because they are imprecise jargon, and that's fine. But the fact remains, you must learn the jargon, to do your job.
It can be intimidating, but it's required. Just about every one of those terms exists and its use adopted by your group because there was no better alternative.
I worked for... well, it's basically an appstore, which sells "extensions" to a framework. It has a bunch of terms, including these closely-related terms:
- Extension: The product that users buy.
- Archive: A zipfile the developer uploads, containing a single version of the Extension.
- Package: Mostly means the same as Archive.
- Shared Package: a package that's included as a library for other packages.
- MetaPackage: a package that includes shared packages as libraries.
- Version: The zipfile, and its associated metadata.
- Product: Synonym for Extension, used when referring to the Developer Portal, rather than the Store.
- Product Detail: Synonym for Version, used when referring to the Developer Portal, rather than the Store.
Each one of these is a very, very specific thing. Any one of them can be confused with another, and often is. A developer, asking for help uploading their zipfile, might call it any of these, or zipfile, file, software, or more. And Support needs to be prepared for that.
But internally, when I say "is this data part of the Extension?" my colleagues will know exactly what I'm referring to and say "ProductDetails feels a better fit".
They don't need to add "This is data that varies with each uploaded version of the developer's software, and it's data that only DevPortal uses, so it would be better to store it in the Product Details database table." They can say that, to explain their rationale, but it's all implied by our common knowledge of the terms used.
These terms didn't arise by accident.
We sat down, every time there was confusion within the team, and hammered out exactly what we meant by each one. We did our best to pick and define terms that pre-empted confusion. And still we sometimes wrote code that used one term but meant another.
As others have suggested here, we defined them in writing so that people coming to the team could wrap their head around the great swathes of technical, domain-knowledge-dependent language... or jargon.
You need to learn these terms to do your job
If you come to the team, you need to use these terms. There is no point using your own language or terms. That's actively counterproductive.
In another term, we had terms like "sprite", "avatar", "frame", "pose", "species", "character" and "player" - each a distinct layer of abstraction in the display of a character in a game. Despite very carefully defining each term, we had two teams developing two different systems, and when we linked them together, we discovered that both teams' usages hadn't quite lined up...
Naming things is hard. But not doing it at all? Not having a shared technical vocabulary? That way lies craziness.