Getting ready to speak at my first PASS Summit

I’m speaking at my very first PASS Summit this year!

I intend to ‘blog about my experience with my first PASS Summit. Hopefully, my exploits will help others who, like me, are also preparing for the first PASS Summit. This represents the first of those articles.

As I write this, PASS Summit is still four months away. Nevertheless, preparations are in full swing. My flight and AirBnB reservations for Seattle are already set. It’s been a while since I was last in Seattle (I think my last trip was in 2005). Seattle is one of my favorite west coast cities to visit, and I always look forward to trips out to the Pacific Northwest. My only regret about this trip is that baseball season will be over by then, so I won’t be able to catch a Mariners game while I’m there.

I do not intend to rent a car for this trip. To be honest, I’m becoming more and more paranoid about driving a car I don’t own in a metropolitan area with which I’m only vaguely familiar. I did rent a car for SQL Saturday in Washington, and driving around the Beltway was a harrowing experience; during that trip, I became very concerned about returning my rental car with a dent. So for PASS Summit, I intend to rely on public transportation; all my stops — Sea-Tac Airport, my AirBnB, and the Convention Center — are all along the light rail line. If I need a car, I’ll bum a ride off someone, or I’ll contact Uber or Lyft.

Prep work for the event itself on my end is also rolling as well. I’ve gotten emails from PASS about what I need to do to get ready. I’ve registered as a speaker, and I put my presentation into a new PowerPoint template supplied by PASS (and in doing so, I think I made my presentation even better — a lot of the changes will likely end up going into my regular slides). They’re supposed to review my slides, so I’m waiting for them to get back to me as to what changes (if any) I need to make. There are some things about my prep I’m not allowed to discuss — per PASS rules, I’m not allowed to discuss some things until they’ve announced it first — so, alas, I can’t talk about all my prep work.

Last night, I was at Ed Pollack‘s house, helping to prep for this weekend’s SQL Saturday. Knowing that Ed has experience speaking at PASS Summit (he’ll be speaking at his fourth this year), I asked him what I should expect. He told me to “expect at least one question that you can’t answer” during my presentation — maybe something impossible to answer, something I don’t know, or even something that has nothing to do with my presentation. He also told me that PASS Summit would be very busy — apparently there are many activities around PASS Summit that take place. I have friends and family either in or near Seattle; we’ll see how much of a chance I’ll have to get together with them.

I also figure that Matt Cushing‘s advice will likely come into play here. A good chunk of his presentation revolves around activities at PASS Summit. I guess I’ll find out in November how much of it comes into play!

Another thing on my mind is room setups. Although I’ve spoken at many SQL Saturdays, even the largest room in which I’ve spoken pales in comparison to the rooms at PASS Summit. I’m not necessarily nervous about speaking in front of a large crowd — I lost my sense of stage fright a long time ago — as much as I am curious as to how it’s going to work. It’s not something I’ll need to be concerned about until I’m closer to the date, but it is, nevertheless, something that’s on my mind.

I did a Google search for “what to expect at PASS Summit” and came across some interesting links. Some of those links are below (admittedly, I’m listing these for my own reference).

It’s still four months to PASS Summit, but a number of things are already in motion. I’ll be writing more about my experiences as we get closer to November!


July 20 — SQL Saturday, Albany, NY

On Saturday, July 20 (one week from tomorrow), the Capital Area SQL Server User Group (CASSUG) will host SQL Saturday for the sixth time in Albany, NY!

For those of you who are not regular readers of my ‘blog, SQL Saturday is a daylong conference centered mostly (but not entirely) around data topics related to SQL Server. It’s also a great networking event, and an opportunity to hook up with a number of data professionals! Check out the schedule to see what sessions interest you!

And yes, I am presenting, too! I will do a brand-new presentation about ‘blogging, as well as a lightning talk about business cards! I always look forward to doing presentations in my own backyard!

Additionally, there are three pre-con sessions on Friday, July 19. Unlike SQL Saturday, these sessions are not free, but they provide quality daylong training for specific topics at a decent price. Information about these pre-cons can also be found on the web site!

For more information and to register for the event, visit our website! Upstate New York is a great place to visit during the summertime! Hope to see you there!

Upcoming speaking engagements (as of 7/11/2019)

I’ve had several speaking schedule updates since my last update, so I figured another update was in order.

Here are upcoming speaking engagements for which I am confirmed.

I’ve applied to speak at this event, but I am not yet confirmed.

So it appears that I’m going to be busy the next few months. Hopefully, I’ll see you at an event near you!

Getting past the first draft

“No thinking — that comes later. You must write your first draft with your heart. You rewrite with your head. The first key to writing is… to write, not to think!”

William Forrester (Sean Connery), Finding Forrester (via IMDb)

“The secret to life is editing. Write that down. Okay, now cross it out.”

William Safire, 1990 Syracuse University commencement speech

“What no wife of a writer can ever understand is that a writer is working when he’s staring out of the window.”

Burton Rascoe

“Just do it.”


I wrote before that technical writer’s block is a thing. There have been more times than I care to admit where I’ve spent a good chunk of my day just staring at the blank Word template sitting on the screen in front of me.

I recently spent time struggling with such a document. I was assigned to document one of our applications, and I have to admit that I’m having a really tough time with it. Sometimes, one of the hardest things to do in writing (or just about any other endeavor, for that matter — writing software code and songs comes to mind) is simply getting started. I got to the point where I took the advice of William Forrester/Sean Connery and Nike, whose quotes you see above, and “just did it.”

I went through the application (ed. note: see my earlier article about playing with an application) and just started grabbing a few semi-random screen captures. I pasted the screen shots into my Word document, thinking maybe they’d be valuable to use in the document somewhere later. As I went through the functionality in the application, I wrote a few descriptive comments to go along with my screen captures.

That may very well have been the spark that I needed. As I continue this exercise, I’m finding that my document is starting to gain a semblance of structure. In the back of my head, I’m starting to get an idea of how the document will be organized. At some point, I’ll take what I’ve “thrown together” and try to figure out how to make the pieces fit.

This approach doesn’t always work. There are some circumstances where you want to plan it out — you don’t want to just haphazardly throw a building together, for example. But in some cases where creativity is more important than advance planning, mindlessly trying something might just be the spark you need to get yourself going.

Playing in the sandbox is important for documentation

While working on a user guide, I realized that I had administrative rights to the application I was trying to document. That was all well and good, except that I was trying to write a non-admin user guide, and I needed to know how someone who didn’t have admin rights saw the application. Fortunately, one of my co-workers sent me an application URL and a testing user login I could use that simulated exactly what I needed.

That brings me to today’s article. Many application development environments make use of a sandbox, or some other development, environment where a developer can play to their heart’s content — that is, some place where someone trying to test or develop applications can play with the app without having to worry about breaking anything important. That same testing environment is just as important for a technical writer.

Much of my work as a technical writer involves putting myself in an end user’s shoes. I’ll often go through an interface and document the steps a user might use, what a user might see on the screen, and the effects of certain buttons and links. One of my most frequent questions when I work on documenting an application is, “what happens when I click this?” After I do so, hopefully my next response isn’t “oh crap!”

This is why a tech writer needs access to a testing environment. Like application developers who need to test within a safe environment, a person documenting the system needs to be able to document the system and be able to do so knowing that (s)he won’t adversely affect the application by playing with the system.

I wrote previously that a tech writer can help an application developer, and vice versa. Indeed, the tech writer can function as an in-house QA analyst. In order to write good documentation, the writer needs a realistic environment in which (s)he experiences what an end user might see. Having a sandbox environment in which a writer can “play” provides exactly that type of environment. As an added bonus, not only does this allow the tech writer to produce better documentation, it allows that person to provide feedback regarding the application, which ultimately results in a better application.

Don’t like reading terms and conditions? It’s not just you

During my lunch break, I came across this article in the New York Times. It talks about privacy policies for a number of companies — and the vast majority of them are nearly incomprehensible. According to the metrics in the article, comprehending privacy policies requires a minimum of a college degree — and even then, they may not be understandable. As mentioned in the article, the policies were not written to inform the public (read: you) as much as to protect the company. It brought to mind a research article that I read in grad school. It had to do with legal documents, the language of legalese, and how it was nearly incomprehensible. I don’t remember the specifics of it (grad school was a long time ago), but the gist of it was that these documents were purposely written that way in order that any ambiguous language was eliminated and things were made clear. And when I say “clear,” I mean that definitions were defined and unequivocal. Readable, however, is another story.

I could get into data security and how privacy policies exist for your protection, but that’s not why I’m writing this article. (I’ll leave it to people like Steve Jones to address that aspect.) Rather, I’m writing this because I’m a technical writer (among other things), and document readability is a big deal to me. Indeed, this is a major point of emphasis in both of my presentations about talking to non-techies and documentation, and is one of my biggest document pet peeves.

Readability is a huge deal in documentation. Legalese may be a big deal for making sure definitions are unambiguous, but it is inappropriate for something like, say, step-by-step instructions. When I’m writing instructions, I follow a rule of thumb where if an instruction takes longer than a few seconds for the reader to understand, the instruction has failed. I continue to be appalled by technologists who insist on writing every little bit of detail in their instructions and end up with a “step by step” that is one big black body of text. And I’m continually annoyed when that person says, “it’s right there in the documentation,” but the information you seek is buried somewhere in the middle of the 100+ lines of text that (s)he wrote that takes about an hour to read.

When I talk about documentation and instructing people, one tenet that I actively push is the KISS principle. But even this is not easy to do, and people take that for granted. Indeed, this is what technical writers, UX/UI developers, and instructors do; they are in the business of taking incomprehensible technical language and translating it for people to understand.

Do privacy policies really need to be that incomprehensible? I don’t have an answer to that right now; that might be another article for another time. But what I do know is, if their intent is to inform people, especially the general public, they fail miserably.

SQL Saturday Virginia Beach — the debrief

My wife and I arrived home in Troy, NY around 10 pm last night after driving all day from Norfolk, VA. Despite the lengthy drive home from Virginia, it was, nevertheless, a fun and fruitful trip!

First, Greg Moore, who also attended SQL Saturday #839, summed up his assessment of the event in his article here. Go ahead and read his article. I don’t think I could’ve summed it up much better than he did.

As is the case with most SQL Saturday events, I had a chance to network and connect with a number of people. Most notably, I had the opportunity to meet Andy Leonard, who has written a number of books, writes frequently for SQLServerCentral, and is considered a rock star among SQL circles. I told him about my writing exploits, and he hooked me up with the editor at Apress publishing. Once I’ve had a chance to get everything settled and back into the normal routine after nearly a week away, I’ll have a conversation with him. Could a book be in my future? I’ve always dreamed about having my name on a book. We’ll see!

My own presentation went well, although I still think it could be better. This was the first time I’d given this presentation since I revamped my slides. I’ll have to see what feedback I received and use it to make the presentation even better.

I met a fellow fraternity brother who recognized the letters on the hat I was wearing!

I also had another textbook example about how your clothing can initiate a networking opportunity! On Friday, my wife and I were enjoying the Norfolk Harborfest. While walking through the park, a guy recognized the letters on the baseball cap I was wearing, and came over to say hi! He was a fellow fraternity brother from the chapter at Norfolk State University. We took the photo you see above. Always a pleasure to meet another fraternity brother!

The rest of the trip was a great time! I knew that there was a plethora of activities around Norfolk/Virginia Beach, and suggested to my wife that we make a vacation out of it. We hit Colonial Williamsburg, the Chesapeake Bay Bridge-Tunnel, and the beach while we were there.

Although it was a lengthy trip, it was a good one! I look forward to doing it again at some point!