Don’t use acronyms or nonsense words for objects, software, or processes. In general, anything that requires an explanation inhibits communication. We don’t want people to have to memorize a glossary just to function.
I noticed a creeping tendency to use made-up acronyms at SpaceX and Tesla. Excessive use of made-up acronyms is a significant impediment to communication, and keeping communication clear as we grow is incredibly important.
A few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one actually remembers all these acronyms, and people don’t want to seem dumb in a meeting, so they just sit there in ignorance.
I told people the acronyms needed to stop immediately or I would take drastic action. Unless an acronym is approved by me, it should not enter the SpaceX glossary. If there is an existing acronym that cannot reasonably be justified, it should be eliminated.
The key test for an acronym is to ask whether it helps or hurts communication. An acronym that most engineers outside of SpaceX already know, such as GUI (graphical user interface), is fine to use. It is also okay to use a few acronyms or contractions every now and again, assuming I have approved them. For example, we use MVac and M9 instead of Merlin 1C-Vacuum or Merlin 1C-Sea Level. But they need to be kept to a minimum.292
The most simple, straightforward, low-ego terms are generally best. You want to close the loop on reality hard.293