Skip to main content

The problem with acronyms

Have you ever attended a presentation and been confused as to what an acronym meant? Have you asked what it meant or did you wait in vain for someone else to ask first? Have you thought you knew what it meant only to realize after a minute or two that you didn't?
The problem with not defining the acronyms that you use in a presentation or talk are that a particular acronym means different thing to different people.

We all know, or think we know, what certain acronyms mean - SDK means Software Development Kit, JVM is Java Virtual Machine - and some acronyms are so well known that they can be relied upon to always mean the same thing. Does anyone use the acronym IBM to mean anything other than International Business Machines? However many acronyms are reused for different meanings.

The other problem is that it can take a few seconds to remember or to work out what the acronym means. That is time you should have been paying more attention to the presenter.

When presenting please define your acronyms, even if it is to a room of your peers, as it is almost certain someone doesn't know what the acronym means and will interrupt to ask, breaking your train of thought and prompting other questions to happen. It is also annoying when you get asked to elaborate on something or to clarify a point when the question about the acronym affected the flow of the presentation!

Is it also necessary to use the acronym at all? It doesn't save much, if any time, to say the acronym as it does to say the full expression. It saves time for your audience when they don't have to decipher the acronyms and can pay more attention to the actual content of the presentation.


Comments

Popular posts from this blog

"No child processes" error

A problem was reported by a customer. They were getting a failure and in the logs it reported error → waitpid failed 'Reason: No child processes' The “No child processes” error came from waitpid() after using  fork/spawn to launch a utility to load data into a data base. Upon detailed investigation it appears it is possible that some other process that the user is running has changed the default handler for SIGCHLD - possibly the shell (e.g. bash!) used to launch our server processes.  If the signal handler is set to SIG_IGN then when a process is started using fork()/exec() the return code from the process is NOT returned and waitpid() cannot retrieve the response code. The most likely reason for "No child processes" error from waitpid() is that the signal handler for child processes (SIGCHLD) is not set to SIG_DFL. This should not be possible however it seems that on Linux a process run in the shell (or maybe a shell process) can set it to SIG_IG...