Upcoming speaking engagements (as of 6/17/2019)

It’s been a fun year for SQL Saturday so far! I’ve spoken at three SQL Saturdays and two user group meetings so far this year, and more speaking engagements are on the horizon.

As of today, I am only confirmed to speak at one SQL Saturday, but it’s a big one.

  • SQL Saturday #855, Albany, NY, July 20: this is my hometown event, and I’m always honored to be presenting in my own backyard! I will be doing a brand-new presentation, about ‘blogging. (No, I still haven’t finished my slides yet!) Additionally, I got the official word this morning that I will be also be doing a lightning talk. I will do a ten-minute talk about what I think might very well be the most important business networking tool you could have.

    Come on out and see me present in my home turf! Use the link above to register for this great event!

There are also a number of events to which I’ve applied to speak. I may not know for a little while as to whether or not I’m picked, but so far, the list includes these events.

  • SQL Saturday #892, Providence, RI, August 24: When I spoke to John Miner (who is organizing this event) in Virginia Beach last weekend, he sounded pretty certain that I would be speaking. I don’t want to say too much until I get the official word, but nevertheless, this is a good event to attend. Providence is always a good one!
  • SQL Saturday #912, New York City, October 5: I’ve attended SQL Saturday in NYC more than any other event, going all the way back to my very first one in 2010! I’ve only been selected to speak there once (last year). Let’s see if I’m picked again.
  • PASS Summit, Seattle, WA, November 5-8: This is considered the “Super Bowl of SQL Saturdays.” I’m hoping!

SQL Saturday/PASS events are always a good time, and I tend to give pretty good presentations (or at least I’ve been told as much). Hopefully, I’ll see you at one near you sometime soon!

Advertisements

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!

I’m speaking at SQL Saturday Virginia Beach — June 8

Saturday, June 8 is coming soon (a week from this Saturday). How will you be spending it?

For me, I will be speaking at SQL Saturday #839, Virginia Beach that day. I will be doing my presentation entitled: “Disaster Documents: The role of documentation in disaster recovery.” In my presentation, I tell the story of my company and my workgroup — which had an office in the World Trade Center on September 11, 2001. I had written several documents for our organization, and they ended up being critical to our recovery.

Come on out and check out my presentation. I can always use a good audience. Hope to see you there!

Three years a ‘blogger — what a long, strange trip it’s been

As of this Friday, I will have been writing my ‘blog for three years. Happy anniversary to me, I suppose!

I originally started my ‘blog to supplement my SQL Saturday presentations, but since then, it’s taken on a life of its own. I’ve written about a number of topics, mostly about professional development. I’ve dabbled a bit in some technical topics such as SQL Server and BI. I’ve even written about networking and the job hunt. As a professional technical communicator, I write a lot about technical writing and communication. Every now and then, I’ll write about something that has nothing to do with professional topics, but might be of interest to professionals, anyway. I write about whatever’s on my mind. In a way, I think of my ‘blog as my own online diary, except that instead of writing a personal journal where the only people who’d see it are myself and anyone who comes across it after I’m dead, I’m writing it for the entire online world to see.

I think a ‘blog can be a good experience for anyone looking to advance his or her career. Indeed, I have a presentation in the works about exactly this topic. As of this article, it’s still a work in progress. I haven’t done much more than create a PowerPoint template and put a few thoughts into it, but I have already submitted it for SQL Saturdays in Albany and Providence. We’ll see if it gets any bites, and hopefully, I’ll be presenting it at a SQL Saturday near you!

(Note: if you’re a ‘blogger, and would like to contribute something about your experience to the presentation, please feel free to mention something in the comments. Maybe I’ll use it in my presentation! Don’t worry, I’ll make sure I give you credit!)

I have some more thoughts about ‘blogging, including things I’ve learned and tips for people who are looking to get started with ‘blogging, but I’ll save those thoughts for another time. (These are all things that I intend to cover in my presentation.) For now, I’ll just say that it’s been a fun three years, and I hope to keep going for many more!

Testing something? What’s the test plan?

Imagine if you will that you’ve been asked to test a product. The product could be anything — software, a car, a kitchen appliance, a piece of sports equipment, whatever. For the purposes of this article, we’ll say you’re working at some company, and you’ve been asked to test a piece of software.

You’re told to go into an application, and you’re given this instruction.

“Okay, test it and see if it works.”

That’s it.

How would you feel? Vague? Confused? Frustrated? Abandoned? All of the above? Something else?

Well, I, myself, have been put into this situation more times than I care to admit. It’s one of the most frustrating job situations I’ve ever been thrust into.

What, exactly, constitutes “see if it works”? I could simply start the application, see if it starts, and say, “okay, it works.” I suspect that that’s not what the people who make the request are looking for. Yet time and again, I get a request from a developer or a designer to test something, and that’s the only instruction I’m given.

And it’s frustrating like you wouldn’t believe.

What’s even more frustrating is when (not if) the application comes back with some kind of problem, and the people who asked you to test come back with, “you said you tested this! Why is this broken?”

Want to know why there’s so much friction between developers and QA personnel? This is a likely reason. This is something that definitely falls under my list of documentation pet peeves.

The fact is, if you develop a product, and you need to test it for functionality, you need to specify what it is you’re looking to test. You need to define — and spell out — what constitutes a “working product” from one that’s “defective.” Just because a car starts doesn’t mean it’s working. You still need to put it in gear, drive it, steer it, and make sure that it can stop.

If you are creating a product, you need to describe what parameters are required for it to pass testing. If you’re asking someone in quality control to test your product, provide the tester with guidelines as to what should be checked to ensure the product is functional. Better, provide him or her with a checklist to determine whether or not your product can be released. If you discover additional items that need to be tested, then update the checklist.

(If you want to know more about checklists, I highly recommend The Checklist Manifesto by Atul Gawande. It’s actually a surprisingly excellent read.)

So any time you release a product for testing, tell the testers what it is that constitutes a “good” product. Don’t just send it off with vague instructions to “make sure it works” and expect it to be tested. More often that not, that will result in a failed product — and defeat the entire purpose of why you’re looking to test it in the first place.

SQL Saturday #835, Philadelphia — 5/4/19 (a week from this Saturday)

I just received an email from the organizers of SQL Saturday #835, saying that I should ‘blog about the upcoming event. Okay, I will oblige!

This is the fourth consecutive year that I am speaking at Philadelphia SQL Saturday, and they’ve all been fun experiences! (Last year, I even wrote an article in which I documented my trip!)

This year, I will be doing my presentation on tech writing and documentation.

Image result for chewbacca
Chewie says, “May the 4th be with you at SQL Saturday!”

And… because this year’s Philadelphia SQL Saturday falls on May 4, attendees are encouraged to wear their favorite Star Wars garb. Yes, I intend to participate. No, I’m not saying how. You’ll just have to wait until May 4 to find out!

So if you’re interested in databases, data science, technology, professional development, or just want to hang out with a bunch of computer geeks, and you’re in southeastern Pennsylvania or southern New Jersey a week from Saturday, go register on their site, and we’ll see you there. May the fourth be with you!