For those of you following along at home, you’ll recall that my first presentation was scheduled for this past Friday. We have a regular developers’ forum at work where employees or outside vendors will talk about some new technology or something they’re working on. Being a DBA in a department of developers, the subject matter isn’t always directly pertinent to my responsibilities, but it always helps to know what folks are working on and think about what kind of back end database support it’s going to involve.
Choosing the content
When I decided I wanted to start presenting within the SQL Server community, I figured the best (and least threatening) place to start was at one of these forum sessions. I just had to decide what to talk about. It needed to be pertinent to developers, since that was my audience, but at the same time I didn’t want to “preach to the choir”, so to speak. Cover developer-centric topics like T-SQL best practices, etc, that, as developers, they should know more about than I. Or maybe I shouldn’t assume? I’m not sure.
Anyway, I was working with a developer and showing him how to implement Service Broker as a replication alternative, and it occurred to me that there was another database application that could also be using Service Broker in a similar capacity. Then it dawned on me, why not talk about Service Broker? I knew I could easily fill an hour with just that one subject, lots of presenters do. But that got me thinking that maybe a better use of that hour would be to give them a high-level introduction to a few different features in SQL Server that they might not be aware of. Based on the needs I’d seen, I decided to cover database snapshots and data compression, in addition to Service Broker. And so, “SQL Server Features for Developers: What you should be using and why” was born. Yeah, I need to work on my titles.
Putting it together
The content wasn’t too hard to develop. For snapshots and compression most of the content came from my blog. Service Broker was a little harder. For one thing, while I’d used it a couple of times, I didn’t know enough about its inner workings to feel comfortable talking about it. The other challenge was how to explain it. I read all sorts of articles online, looked at other people’s slide decks, but nothing really clicked until I read the Service Broker section in Professional Microsoft SQL Server 2008 Administration. In it, they use an analogy of the postal service to explain what a service name is. I thought about that for a while and I realized that our internal timesheet process was an even better analogy for the entire Service Broker solution. So I used that to explain all the components, and for the demo I showed them how to program it.
I got more and more nervous as the date approached. I suddenly felt completely unprepared, even though, rationally, I knew I knew this stuff. I found myself rehearsing the intro and first few slides in my head, over and over. Wednesday night I gave the presentation to my household. Based on feedback from that, I made some last minute tweaks to the slide deck and practiced on my own one more time. I was as ready as I’d ever be.
What I never anticipated was the urge to vomit. But there it was, that… feeling in the back of my throat. Making me need to swallow after almost every sentence. I’d done public speaking and theater in college, and I don’t recall that ever happening. All I could think (as the rest of me somehow kept on talking) was “Woman! Don’t you dare puke in front of all these people!” However, thanks to all the rehearsing I’d done, no one seemed to notice (or so they said afterwards). It didn’t go off without a hitch, however. During my compression demo I used sys.dm_db_index_physical_stats to show the before and after page count and row size. Well, either I hadn’t uncompressed the object after my last practice run, or I got my scripts mixed up, I’m still not sure, but I was showing them the “before” stats when I noticed they were wrong. What I was seeing was the “after” stats. So I made a little joke about ruining the “big reveal” and everyone laughed it off, including myself. I corrected the mistake and continued on with the demo. From then on I was much more relaxed.
Unfortunately, we don’t have any sort of formal review process for these presentations, but I did have a number of folks approach me afterwards and tell me I did a great job. And even a couple of managers stuck around afterwards to ask more about some of the features I covered. So I definitely think the seeds have been planted, which was the whole point. All in all, I feel really good about the experience. I’m looking forward to my next presentation at the Ohio North SQL Server User Group (@ONSSUG) meeting on October 4. And, once again, I feel completely unprepared, lol. Hopefully this time I won’t feel the urge to vomit. That would be nice.