As a followup to yesterday’s article, I thought it might be fitting to talk about presentation ideas.
Despite the fact that I speak regularly at SQL Saturday, none of my presentations (up to this point) have anything to do with SQL Server or even anything data-related. My topics revolve mostly around documentation and communication. So how do I go about coming up with presentation topics?
To answer this, I suppose I should go back to the beginning, and (re-)tell the tale as to how I got involved.
Back when I was primarily a SQL Saturday attendee, I knew I wanted to get involved. The question was, how? At the time, I looked around at the people attending the event, and I said to myself, “these people probably know more about SQL Server than I do. What can I present that these people would find interesting?”
In the early days of our user group (I was one of the original co-founders and members), we sought out speakers to present. I thought about data-related topics. I even took a turn one meeting where we were encouraged to bring up SQL-related issues as discussion topics. But when it came to ideas for data-related topics, I kept coming up empty.
I thought about a time at one of my jobs where I became an accidental customer service analyst. As a developer, I was not allowed to speak with end-users, but one day, I received a phone call from a user. It turned out that he had gotten my number from someone who was not supposed to give out my number. I was able to walk him through and satisfactorily resolve his issue. In fact, I did such a good job with it that, from that point forward, I became one of the few developer/analysts who was allowed to talk to customers. It made me realize that I had a knack of being able to discuss technology with end-users without being condescending to them.
During one user group meeting, I jotted some notes down. By the end of the meeting, I had come up with enough material for a presentation. I ran my idea past my fellow user group attendees, all of whom said, “that would make a great presentation!”
While that ended up being a good presentation, I’ve tried not to rest on my laurels. I still try to come up with new presentation ideas. I’ve come up with several since then, and I’m still trying to come up with more.
When I think about presentation ideas, I generally keep these thoughts in mind.
Is it a topic that attendees will find interesting?
Is it unique?
Is it something about which I’m knowledgeable, and I feel comfortable talking about?
Is it something I can present within an hour? And do I need to cut it back to an hour, or do I need to fill it in to an hour?
I still remember a piece of advice that Chris Bell, a DBA and fellow SQL Saturday speaker, once told me: “an expert is someone who knows something that you don’t.” That was profound advice, and I’ve never forgotten it. So far, it’s served me well in my speaking endeavors.
So if you struggle to come up with presentation ideas (like I do!), hopefully this will help you get the ball rolling. I look forward to seeing your presentation soon!
“The reward for work well done is the opportunity to do more.”
As a Syracuse alumnus and sports fan, I’m looking forward to this upcoming football season. Orange fans are excited for this season after last season’s 10-3 breakthrough, the first time that Syracuse has won ten football games in a season since 2001. Season ticket sales are up this year (and I’m happy to say that I am one of those season ticket holders). I’m looking forward to attending games this season!
In a recent interview, Syracuse football coach Dino Babers said that getting the team to break through with a great season (after years of mediocre ones) was the “easy” part. The harder part, he said, is maintaining it. As he often puts it, he wants to be “consistently good, not occasionally great.” Breaking through is a great thing, but after you’ve done so, how do you maintain that success?
I thought about this recently in regard to SQL Saturday presentations. One of my friends and fellow speakers gives a great presentation, but I do have one concern about it: it’s only one presentation. I’m not sure how long he’ll be speaking at SQL Saturday if he keeps submitting the same presentation again and again. I’d like to see him do more presentations, and I hope to see him at more events. Yes, he has a good presentation, but what does he do for an encore?
It’s for that reason why I look for more presentation ideas. As of this article, I have a brand new presentation idea that, right now, only exists in the back of my head. I listed it so that I’d remember to work on it. If I come up with what might potentially be a good presentation idea, I’ll set the idea aside so I can work on it. I want to make sure that I have fresh ideas. I love speaking at SQL Saturday, and I’ve been doing it for four years. I want to keep doing so. To do that, I want to make sure I have new material. While I do occasionally recycle my presentations (it’s unavoidable), I try not to resubmit the same presentations over and over to events.
For those of you who are looking to get your career off the ground, the same holds true for career endeavors. A great job that you did on a single project will often be enough to get you in the door. But once you’re in the door, how do you stay there? Breaking through on a project is the easy part; the harder part is sustaining that success. Once you’ve achieved something, can you do it again? And again?
If you are able to sustain success, you develop a reputation as someone who can deliver. That’s how you build a career. Achievements are great, but once you attain them, what do you do for an encore?
After I logged into my computer, a pop-up window appeared. It was my Docker application, telling me that an update was available and ready to install. Okay, I said to myself, and clicked the button to proceed.
Except… nothing happened.
I clicked it again. And again. And again. I mashed the mouse button. Nothing. I decided there was a problem with the interface, went on with my work, and forgot all about it. At one point, I saw a Docker window appear, saying updates were being applied. Okay. Again, I went back to what I was doing.
I didn’t think anything of it — until I looked at my taskbar several minutes later. All along the taskbar were several new — and identical — icons that I hadn’t seen before, roughly one for each time that I had hit the mouse button. When I clicked each icon, I was greeted with a window that said “installation failed.” Well, almost all. The second-to-last one I clicked said, “installation succeeded.”
Yet another example of horrible design rears its ugly head.
As an application end user, if I click something where it says “click here,” I expect — and demand — that it does something. It doesn’t matter what it is. Granted, I would prefer that it performs the action that I expect when I click it, but even if all it does is change the mouse pointer, display an “in progress” icon, or display an error message, I expect some kind of response that indicates that my action did something.
An action that results in nothing is a huge pet peeve of mine, and, in my opinion, is extremely horrible design. A click that does nothing tells me that the application is doing exactly that: nothing. Having an action with no response is not only annoying, it can be potentially dangerous. What if — hypothetically — clicking a button resulted in lost data, but there was no indication as such?
A reaction is a form of feedback. If I click a button, a reaction — even if all it is is an in-progress icon — tells me that the application is doing something. If I click a button, and it does nothing, then I expect the application is doing nothing. An action without any reaction results in frustration on the part of the end user, and potentially dangerous side effects if the application performs an action that the user doesn’t expect.
If this is how you design your UX, then you need to rethink your design. When it comes to interfaces, every action must have a reaction.
For those of you who have application development experience, how many times have you come across old code that you’d written and said to yourself, “what the F was I thinking?!?”
As someone with development experience, it’s happened to me more often than I can count. And as someone with tech writing experience, I can tell you that it applies to documentation as well.
As a technical writer, I’m often tasked with rewriting old documents that are out-of-date or no longer applicable. In the old days (i.e. before I knew better), I would essentially overwrite old documentation with the new, and often deleted the old. Now that I have more experience under my belt, I know now that that was the absolute worst practice that I could have done.
For starters, I used to have the mindset that the information in old documents was no longer relevant. The processes have changed, I used to tell myself. Why should I keep these documents around?
If you have this mindset, as I once did, I urge you to purge it. It is a poisonous attitude to have. As it turns out, old documents are extremely relevant, even if their information is out of date. Old documents are important for reference. I’ve often found myself referring back to previous versions when rewriting documentation.
I recently wound up a project that involved a rewrite of an application document. The application had been rebuilt from the ground up, and the documentation had to be rewritten to accommodate it. While documenting the testbed, I came across a number of functions that, with the limited testing dataset, didn’t seem to do anything. I went to the predecessor documentation and found what I was looking for.
Old documents are often also important in answering a simple question: why? As in, why was such-and-such process designed this way? What was this originally supposed to do? Why was this function changed? Many of these cannot be answered just by looking at application code; often, the answers are found in old documents.
These days, I make it a point to not overwrite old documentation. I back up old documents and either rename them or put them into an archive folder. I haven’t yet implemented a version control system to archive documents (we use Git in my office). If anyone makes use of version control systems such as Vault, Git, Subversion, or MS Azure DevOps (formerly TFS) to maintain documentation versions, feel free to mention it in the comments.
So if you are rewriting documentation, make sure you set aside the previous versions. You never know when you’ll need them again.
I arrived home last night around 9:15, after driving four hours (including an hour-long dinner break) from Providence, RI. As usual, it was another great SQL Saturday! As always, I had a blast! And as always, I was wiped out after it was over! Even as I write this, on this Sunday afternoon, I had intended to take care of some work around the house, and ended up taking a nap instead. C’est la vie.
I’ll start with something I did before I even left on Friday. I was getting my things organized and packed for my trip. While going through my briefcase, I came across my laptop dongle. I told myself, “most places these days use HDMI video inputs for their projectors. I haven’t needed it yet. So I’ll just leave it here.” I tossed it back in my briefcase, and packed my laptop without the dongle.
I didn’t know it yet, but I had just shot myself in the foot. (Read on, McDuff.)
I checked into my B&B (a cute New England cape house in North Kingstown, RI) and headed to the speaker’s dinner. One of the B&B’s co-owners told me that the restaurant was a former train station. It sat by some very active railroad tracks. Not only was I able to see trains as they went by, I could feel them. Several Amtrak, Acela, and MBTA commuter trains passed by during dinner.
My session was scheduled for 10:00 on Saturday. Unfortunately, it didn’t go as smoothly as I would have liked. For starters, I found out that the wrong room was listed on the schedule. I went to an empty room, which surprised me, because I was expecting to walk into the previous session already in progress. It turned out that it was down the hall.
Remember how I said that I shot myself in the foot when I didn’t bring my dongle? Here’s where it raised its ugly head. It turned out that the only projector connections were VGA, which I didn’t have on my laptop. I was not able to find an HDMI adapter. That’s when I resorted to Plan B.
Before every SQL Saturday, I always make it a point to upload my slides to the website. They’re there so that attendees can download them. However, they also serve a secondary purpose: my backup, in case something happens with my laptop. Sure enough, I had to resort to it. I used the desktop computer in the classroom, downloaded my slides, and used that for my presentation. (A thought popped into my head while they were downloading: does the desktop have PowerPoint installed?)
I was angry with myself, because I usually take pride in that I’m always prepared — and on this day, I wasn’t. Note to self: always bring the dongle with you. I made a mistake, and I paid for it by losing ten minutes of my presentation time. I suppose I’ll chalk it up as a learning experience, and remember to pack my dongle for next time.
The presentation otherwise went without a hitch. I did tweak it a bit, per the feedback I received the previous time I’d presented it.
I was in for a surprise (a pleasant one, this time!) after my presentation. One of the attendees (the gentleman you see in this picture) introduced himself to me after I was done — and when I saw his name tag, I realized immediately who it was! (For privacy reasons, I’m withholding his name.)
I often peruse the forums on SQLServerCentral.com. It’s my go-to forum whenever I have database-related questions. There are a number of people whom I see regularly on the forum, and I interact with them often enough that I consider them friends. The fantasy football league in which I play came from these forums. There is one person with whom I interact regularly on the forums, including fantasy football. He is our league’s defending champion, and as the only two people in the league who have multiple titles, we are rivals. I’ve been conversing with him for year and years. I consider this man a friend.
This weekend, we met face-to-face for the first time! He attended my presentation, and I had no idea that it was him! His attendance totally blew my mind, and it made my day!
Grant Fritchey gave a great presentation about SQL injection. It blew my mind — and not in a good way. Although SQL injection was identified as a security problem in 1997, it still persists as a problem now in 2019. If nothing else, Grant’s presentation reminded me that we still need to be vigilant about fighting code injection, even with all the safeguards we have in place now.
Probably one of my favorite sessions was the last one of the day. Linda Groszyk, who is a relative newcomer to speaking for SQL Saturday, gave a great presentation called Breaking the Social Code: How to be Socially Intelligent at Work. It was a fantastic session about human psychological dynamics that, I think, everyone should be aware of. I was impressed enough by her presentation that I encouraged her to apply to speak at our SQL Saturday in Albany when it rolls around next July, as well as our user group, if she is able to arrange it! (Greg Moore, if you’re reading this, consider this a heads-up!)
Another weekend, another great SQL Saturday in the books! If you are able to make it to one near you, I encourage you to do so!
Unfortunately, as much as I would like to go, I am unable to attend either Boston or Washington, DC this year because of schedule conflicts.
I did see save-the-dates for Philadelphia (May 2, 2020) and Virginia Beach (June 13, 2020), but those sites are not yet active (and may not be for a while).
I previously saw a save-the-date for Boston BI for March 28, but it is no longer on the calendar. And although it won’t be scheduled (or even discussed) for a while, Albany will likely be at the end of July next year.
So those are my latest speaking schedule updates. Stay tuned for more updates as they become available!