Acronyms and Assumptions

Assumptions can often get us in trouble. People don’t know what you think they know, and they know what you don’t think they know.

I often present to small groups. I ask questions up front to gauge the experience level, but even so I am forced to make some assumptions. Then there are some basics that I assume any database user will have nailed down. I recently spent 90 minutes talking about writing queries and working with Excel to a group of Analysts at a University without realizing that at this particular institution an ‘Analyst’ was actually a ‘Developer.’ This was a big assumption, and I won’t be making that mistake again. But what about the ‘small assumptions?

For years I have talked about DDL and DML. I just throw these terms out like folks know what they mean. Apparently there are senior DBAs out there who are not familiar with these terms.

This makes me such a hypocrite.

It drives me nuts when I am in a call or in a training session and people start throwing out acronyms. What’s even worse is when you are working with technical terms in print. I always type out the word or phrase and follow it with the acronym in parentheses. Unfortunately my speaking habits do not match up 100%.

New Year’s Resolution
When speaking, I will follow any acronym with an immediate clarification. Even if it’s on Twitter.

Example: Toad makes it easy to generate your DDL (Create or Alter) scripts.

If I can make my audience more comfortable, they are much more likely to walk away from the meeting with the intended message.

@datachick – I’m still of the opinion any DBA should be able to define DDL and DML. Or ACID. Or RDBMS. Or…