On the road to SQL Saturday

“I can’t wait to get on the road again”
— Willie Nelson

For this article, I decided that I would take you on the road with me.  If you’re interested in speaking at a SQL Saturday away from home, I figured that you’d like a taste of what it’s like to travel to an out-of-town SQL Saturday.

Of course, people travel to these events in different ways, so everyone’s traveling experience will be different.  Some people fly to these conferences.  For events in New York City, I usually take Amtrak.  People will travel using the means that makes the most sense to them, and especially in a way that’s cost-effective (as I mentioned in a previous article, we speakers mostly make these trips on our own dime).  Most SQL Saturdays where I apply are generally within a somewhat reasonable driving distance for me.  As of this article, my longest distance traveled to a SQL Saturday is Pittsburgh, which was an eight-hour (one way) drive for me.

So, I decided to document my trip to SQL Saturday #714, Philadelphia.  For this trip, I’m driving.  It’s roughly a four hour drive from my home in Troy, NY to southeast Pennsylvania.  Most of the trip is on interstate highways and through large metropolitan areas (I’ll be skirting the New York metro area on this drive), so the drive won’t seem as tedious as it is on a long stretch of rural highway.

So off we go!

Pre-planning

How early I make travel arrangements depends on what SQL Saturday I apply to speak.  If it’s an event where I’m likely not to be chosen, I’ll usually wait to see if I’m picked before I start making travel plans, although there are some exceptions.  If the event is one where I think I might have a reasonable chance of being chosen, or if it’s one where I can cancel plans if I’m not picked, I’ll make plans as soon as I possibly can.

I’m traveling solo for the Philadelphia trip.  Once in a while, my wife accompanies me on SQL Saturday trips; she knows that she has an open invitation to come along for the ride.  Alas, work and other commitments kept her from doing this trip, so she elected to stay home.

Jerry on the left, and me on the right, when we were in college

For lodging arrangements, I contacted my friend, Jerry, who lives about forty-five minutes from the event site — not necessarily right down the road, but close enough to make it convenient.  Jerry is an old college buddy and fraternity brother; we both attended Syracuse University, and we were in the same Kappa Kappa Psi pledge class.  This is the third consecutive year that I’ve been selected to speak at Philadelphia SQL Saturday, and the third straight year I’ve stayed overnight with Jerry and his family.  I’ve joked with Jerry about making this an annual thing; when I left his house last year, I remember telling him, “I’ll see you next year.”  I guess I wasn’t kidding!

Me and Jerry — a few years later, a little older, and a little grayer!

I Google-mapped directions to both Jerry’s house and the event site in Blue Bell, PA.  When I spoke to Jerry, he informed me that he would be returning from a trip on the same day that I would be driving down.  It was possible that Jerry’s wife would be at home to greet me when I arrived, but even that was uncertain, given Jerry’s travel schedule.  So I made sure that I mapped directions to go directly to the speaker’s dinner on Friday night.

A few days before the event, I finally got a location for the speaker’s dinner (until that point, it was listed as “TBD”).  Once I had that last piece of the travel puzzle, I was able to finalize my plans.

Friday, April 20 — heading down to Philly

I decided to take the day off from work on Friday — not just to prepare for my trip and to drive down, but with my schedule the way it’s been for the past several weeks, I decided I could use the mental break.  It felt good to sleep in this morning.

I took a 45 minute walk in the morning; I’ve been trying to get into the habit of doing so each day, especially lately when I haven’t had time to get to CrossFit.  After a quick shower, I left my house around 12:45, got myself lunch at Panera, and got on the road around 1:45.

Along with a couple of rest stops, I made it to the speaker’s dinner a little after 6:00.  It generally wasn’t a bad drive; the worst traffic was the stop-and-go traffic on US-202 in New Jersey and Pennsylvania.  I had thoughts about getting gas on Route 202 before I crossed into Pennsylvania; gas prices in New Jersey tend to be cheaper.  Unfortunately, almost all the gas stations I passed were on the other side of the highway.  (Those of you who’ve dealt with New Jersey highways know what I mean when I say how much of a pain it is to get to something on the other side of the highway.)  I wasn’t in any danger of running out of gas, so I figured I could wait.  Unfortunately, as I would find out later that night, I probably should have stopped.

Many SQL Saturdays have a speaker’s dinner on Friday night before the event.  It’s a great opportunity to say hi to fellow speakers, reconnect with friends you don’t see very often, and maybe even make new ones.  Today’s dinner was held at an Indian restaurant in Norristown, PA, a few miles from the event site.  I saw several familiar faces when I arrived, including (among others) Greg Moore, Chris Bell, Gigi Bell, Grant Fritchey, Eugene Meidinger, Sebastian Meine, Lisa Margerum, and John Miner, among others.  (I hope I didn’t miss anyone there!)  Gigi, who had met my wife the year before, asked where she was, and said that she forgave her for not coming on this trip.  The food was very good; I went back up for several extra helpings of the Tandoori chicken.

Our speaker’s gift

I left the dinner around 8:30, but not before picking up my ID lanyard and speaker’s gift.

After I left, the first thing I wanted to do was put gas in my car.  This was when I started to regret my decision not to get gas in New Jersey; gas prices around this area were 20 to 30 cents per gallon higher here than it was in Jersey.

I got to Jerry’s house around 9.  I was promptly greeted by their dog, Daisy (for some reason, I keep wanting to refer to her as Sadie).  I spent about an hour or so hanging out with his family in the family room, and decided to go to bed at the same time Jerry put his son to bed.

Something I ate definitely didn’t agree with me this night; I was feeling somewhat queasy when I went to bed.  I fell asleep quickly, hoping that whatever it was that made me feel ill would clear up in my sleep.  Tomorrow’s going to be a long day.

Saturday, April 21 — SQL Saturday

My alarm woke me up at 6 am.  I took a quick shower, dressed, and went down to the kitchen where Jerry had coffee waiting for me.  I didn’t bother with breakfast; I figured there was going to be plenty of bagels and coffee at the event.  And as I correctly guessed, whatever was bothering me when I went to bed cleared itself up by the morning.  I left Jerry’s house a little after 7:30, and made it to the SQL Saturday location a little after 8:00.

As with most SQL Saturday conferences, signs were out to direct people to the proper site.

SQL Saturday events usually have a speaker’s room where speakers can park themselves and their things; it’s basically a home base for presenters.  I put my things in the speaker’s room and went out to the main reception area, where the vendors had their tables.

The reception area, with the registration and vendor tables

SQL Saturday is funded by sponsors, who usually set up booths at the conferences and include swag and raffle prizes to be given away at the end of the day.  Attendees enter raffles by dropping tickets (that come with their registration packages) at each vendor’s table.  Vendors will raffle off a variety of items, including software licenses, books, Xbox game systems, drones, tablet computers, Bluetooth speakers and headphones, and so on.  Of course, the deal is that when you enter these raffles, you give vendors the opportunity to contact you via email.

As the day got going, I saw a few more familiar faces whom I didn’t see at the previous night’s speaker’s dinner, including Taiob Ali, James Serra, Tracy Boggiano, and Steve Mokszycki.

I made it a point to sit in on Greg’s presentation about how to present.  Number one, I’m giving a very similar presentation in New York City next month.  Number two, his presentation was in the same room as mine.

And number three, Greg is a friend, and I like to heckle him! 🙂

(I said this to Greg as I walked in the room.  His response: “I know where you live!  Better, I know your wife!”)

Greg, as always, gave a very good presentation.  He mentioned a number of points that didn’t occur to me.

At 11:40, my own session started.  I didn’t count, but I’ll guess-timate that there were about seven or eight people in my session.  There was plenty of discussion and a few questions, which is exactly what I want in my presentations.  Well, I would’ve liked more questions, but at least it was a receptive audience.  I don’t want an audience that isn’t receptive; I’ve had that happen before.

I grabbed lunch after my session; barbecue catered by a place called Mission BBQ.  Very tasty!

A month earlier, I was talking to Tracy Boggiano at Rochester SQL Saturday.  She told me that she had taken a number of SQL Saturday trips (a lot more than me!), and was telling me how she had gained weight from all those trips.  Up to this point this weekend, I could definitely see why.

I also saw that massage therapy students were giving free chair massages.  They said they would be there until 4:00.  I told myself to get one after lunch.

During the lunch break, Taiob came up to me and asked me if I would be interested in speaking for his user group out in the Boston area.  It would most likely be a date next year.  Just another example of my efforts paying off!  I told Taiob that yes, I was interested.  He said he would contact me.  He also promised to pick a month where we were unlikely to have snow on the ground!

Sarah Hutchins, a recruiter from Harrisburg, PA, was doing a presentation called “How to Ace Your Job Interview.”  Because it was related to my presentation that morning, I made it a point to sit in.  It was her very first SQL Saturday presentation, and I thought, for her first one, it went very well.  It wasn’t perfect — there were things she could have done better — but I think (and hope) she was pleased with her effort.

James Serra sat next to me during the presentation.  He commented how it seemed that we saw each other at every SQL Saturday, and joked that all of we speakers should just get a bus and take it from conference to conference together!  Indeed, I regularly see a lot of these speakers I mentioned earlier in this article.  It does seem like we travel from event to event!

Sarah’s session went long; it was a little past 3:30 by the time we got out.  I decided to sit out the last round of sessions; by that time, my brain was cooked, and I could use some downtime.  I went to the speaker’s room to relax a bit.

Me getting a chair massage!

It was at that moment that I realized that I’d forgotten about the chair massages.  By then, it was 3:45.  I had fifteen minutes to get one!  I managed to get it in, and it was well worth it!

Sessions started wrapping up around 4:30; around that time, everyone started gathering around the reception area.  The vendor raffles began.  Gigi Bell won a set of Bluetooth headphones.

I got back to Jerry’s house around 6:00.  We hung out for a little while; I worked on this article a bit, and watched his son play Xbox games in the family room.  I told his kids that I wanted to thank them for letting me crash there for the weekend by taking them out to dinner, and they could pick the place.  I took Jerry, his wife Debbie, and their kids to a T.G.I. Fridays for dinner, and went to Rita’s to get dessert.

The rest of the evening was quiet and uneventful.  Jerry and I chatted in his kitchen, while we watched his son play more Xbox in the family room.  I said my goodbyes to his wife and daughter; with my early morning departure time, I didn’t expect to see either of them the next morning.

Sunday, April 22 — heading home

I told Jerry that I was hoping to be on the road by 7 am; I had a mid-afternoon commitment, and needed to get home as soon as I could.  As it turned out, I didn’t get out of bed until 7:30.  It wasn’t a huge deal; it would take me four hours to drive back to Troy.  I figured that if I could be on the road before 9 am, I would be in good shape.

I left his house around 8:30.  On my way out, I said to Jerry, “I’ll see you next year!”  I fully intended to apply to SQL Saturday Philadelphia again the following year, and assuming I was selected (which might be a safe bet, since I’ve gone three straight years), I’d likely be calling upon Jerry to ask if I could utilize his guest room once again.

I took a slightly different route home, since I went directly to the speaker’s dinner on Friday night, rather than stop at Jerry’s house first.  Really, the only difference was that I drove up to Allentown and picked up I-78 to I-287, instead of taking US-202 like I did on my drive down.

I took a break around 10:45 at the Sloatsburg rest stop on the NY Thruway.  As I get older, I’ve noticed that I can’t really drive longer than a couple of hours at a time.  I took about 45 minutes to use the facilities, stretch my legs, grab a cup of coffee and a quick bite to eat, before continuing my trek back home.

My trip odometer when I got home

After about four hours of driving (and not including my rest stop), I pulled into my driveway a little before 1:30 pm.  My trip odometer said that I had driven 541.7 miles on this trip since Friday afternoon.

And that ended yet another SQL Saturday on the road for me.  I was pretty exhausted by the time I got home, but nevertheless, I felt pretty good about notching yet another satisfying SQL Saturday trip on my list!

I hope you enjoyed taking this excursion with me!  My next scheduled SQL Saturday is #716 in New York City next month (this time, I’m taking Amtrak, rather than driving).  Hopefully, this gave you a taste of what it’s like to travel to a conference, and further encourage prospective speakers to go outside of their boundaries.

I’ll see you again from the road!

 

Advertisement

Questionable administrative decisions (I’m looking at you, PASS)

It’s not often that I will call out by name a specific organization for what I deem to be questionable decision-making.  But today, I am making an exception.

Recently, the Professional Association of SQL Server (PASS — the organization that administers SQL Saturday) made a very questionable administrative decision.  In order to submit presentations to SQL Saturday events, all submitters must first register for the event.  Previously, if a speaker’s presentation is accepted for a conference, he or she was automatically registered for the event.

This decision has resulted in an outcry from people affiliated with PASS and SQL Saturday.

I’ll start with an open letter written by my friend, Steve Jones.  (Steve, by the way, is one of the people who first organized SQL Saturday several years ago.)

Tamera Clark, who administers the SQL Saturday Facebook group, also posted the following.

If you haven’t seen the “news” Pass made a huge change to the SQLSaturday sites that impacts both organizers and speakers. There has been no general announcement only to “current” event organizers.

If an event is open and their schedule is not published yet and you have submitted, speakers must REGISTER FOR THE EVENT as an attendee. Organizers can’t approve sessions until you are registered as an attendee.

As a speaker in order to submit to an event, you must register first and are prompted to do so.

*Yes this means organizers will need to contact speakers to get them to register.

*Yes this means you must register for an event and if you are considerate go back and unregister if you don’t get selected or can no longer attend.

*I’ve been told this does not register you 2x for the event.

Things I don’t know:

*What happens to the lunch status if a speaker is selected. Does it update to “compt by event”?

*As a speaker if I change my mind before the event(prior to the schedule being made) and just cancel my registration what happens?

*As a speaker if I change my mind during the process of a schedule being made (ie. session approved but not on schedule) and I cancel my registration what happens?

*As a speaker if I change my mind and the schedule is published what happens when I cancel my registration.

For organizers it looks like we might have gone back in time, now you don’t know if speakers are still attending when not selected. Inflating numbers and causing wait list issues for some.

Finally, I wrote an email to PASS, and I wanted to share it here.

To whom it may concern:

I am writing to strongly object to and to voice my extreme displeasure at PASS’s new policy about requiring speakers to register to an event in order to submit presentations.

This is an extra step that is wholly unnecessary, inconvenient, and detrimental.  All SQL Saturday speakers are volunteers.  The process for allowing speakers to submit should be made easier, not harder.  I have written ‘blog articles, and I have a SQL Saturday presentation, that encourages potential speakers to volunteer to this otherwise-noble event.  Requiring speakers to first register complicates the submission process, and may actually DISCOURAGE, not encourage, new speakers to sign up.

Additionally, if I register, and I am not selected to speak at an event, I will need to take the extra step of canceling my registration.  Number one, that adds to the inconvenience and complication.  Number two, if I should not remember to cancel (as is human nature), that is one more spot that I am denying a potential attendee who is on the waiting list.

I heard that this new policy is to enforce the terms and agreements for SQL Saturday.  This is not an acceptable solution.  If this is about terms and agreements, a more sensible solution would be to include the text along with the speaker’s registration — something along the lines of “if you are accepted to speak, understand that you accept the terms and conditions…” etc.

I strongly urge you to reconsider this policy.  Any policy that makes things difficult is more likely to discourage, not encourage, further participation.

Regards,
Raymond J. Kim
PASS Member
SQL Saturday presenter

I’ve written articles encouraging people to become speakers, as well as put together a presentation that encourages people to present.  In one fell swoop, PASS is threatening to throw that away.

If you are involved with SQL Saturday, and you are as outraged about this policy change as I (and many others) are, I encourage you to contact PASS to voice your displeasure.  By applying pressure to the organization, perhaps they will reverse course.

Reminder: SQL Saturday #714, Philadelphia

This is a reminder that this coming Saturday, April 21, I will be speaking at SQL Saturday #714, Philadelphia (more accurately, Blue Bell, PA).  Go to the link to register for the event.

I will be giving my career/job hunt presentation, entitled: “I lost my job!  Now what?!?”

Hope to see you there!

Setting a good example

I was recently tasked with a project where I would be assisting with developing a data governance document.  Trouble is, I have no idea what a data governance document is supposed to look like.  I looked at what my colleagues had written so far; what they had written looked pretty good, but it still didn’t really give me a good idea as to what the end product would eventually look like.  So I ran a Google search for “data governance document examples.”  Among other things, I came across a PDF document by the Federal Highway Administration, which includes a section called “Data Governance Plan.”  Okay.  Now I have something to go by.

How often have you heard things like “set a good example,” “let’s look at this example,” or “here’s an example of…”?  Whenever I need to look something up, more often than not, the last thing I use is a dictionary definition, or syntax description.  Most times, the first thing I’ll look up is an example of what I want.

Let’s see an example of — well — an example.  More often than not (as I’m sure most of you do), I’ll need to go online to look up things I don’t know very well — like, say, function syntax.

Let’s take, for example, a simple SQL SELECT statement.  I looked up the SELECT statement on MS Books Online and came across this syntax definition.

-- Syntax for SQL Server and Azure SQL Database

<SELECT statement> ::= 
 [ WITH { [ XMLNAMESPACES ,] [ <common_table_expression> [,...n] ] } ] 
 <query_expression> 
 [ ORDER BY { order_by_expression | column_position [ ASC | DESC ] } 
 [ ,...n ] ] 
 [ <FOR Clause>] 
 [ OPTION ( <query_hint> [ ,...n ] ) ] 
<query_expression> ::= 
 { <query_specification> | ( <query_expression> ) } 
 [ { UNION [ ALL ] | EXCEPT | INTERSECT } 
 <query_specification> | ( <query_expression> ) [...n ] ] 
<query_specification> ::= 
SELECT [ ALL | DISTINCT ] 
 [TOP ( expression ) [PERCENT] [ WITH TIES ] ] 
 < select_list > 
 [ INTO new_table ] 
 [ FROM { <table_source> } [ ,...n ] ] 
 [ WHERE <search_condition> ] 
 [ <GROUP BY> ] 
 [ HAVING < search_condition > ]

Is this correct?  Sure.  But how well can you follow it?  For example, what is significant about items in square brackets (“[]”)?  What about items in angle brackets (“<>”)?  How about the pipe character (“|”)?  It takes some time to understand or follow what they’re trying to tell you.  Maybe it’s helpful when you’re trying to understand a concept, but when you’re trying to understand something quickly, this might not work very well for you.

On the other hand, when I scrolled down on the page, I came across a few examples.  Here’s one that illustrates the HAVING clause that I randomly grabbed from the page.

SELECT OrderDateKey, SUM(SalesAmount) AS TotalSales 
FROM FactInternetSales 
GROUP BY OrderDateKey 
HAVING OrderDateKey > 20010000 
ORDER BY OrderDateKey;

Looking at the example, how much better can you comprehend a SELECT statement syntax?  For me, personally, the example works much better than the statement syntax above; I understand the syntax much better by the example than I do by the syntax definition.

How about something for those of you who don’t understand SQL and have no idea what I wrote above?  What about something like, say, a word pronunciation?  I tried to think of a difficult word to pronounce.  I figured the last name of Duke basketball coach Mike Krzyzewski would be a good one.  Wikipedia lists the following for pronouncing his name: “/ʃɪˈʒɛfski/” and “shih-ZHEF-skee.”  Can you easily use /ʃɪˈʒɛfski/ to pronounce his name?  Probably not.  You need an understanding as to what the pronunciation symbols mean.  Granted, clicking it brings you to a pronunciation guide that explains it.  But even so, you still need to look up the symbols, and you need to figure out how to use the guide.  That takes time and effort.  On the other hand, most native English speakers can look at “shih-ZHEF-skee” and have a pretty good idea as to how to pronounce Krzyzewski.

I’ve written in previous articles (check out my articles on tech writing frustration, design, and talking to non-techies) that illustrations are worth a thousand words.  Examples are types of illustrations.  While examples may not necessarily be pictorial, they serve the same purpose: illustrating a concept in a way that’s easier to grasp than just a definition.

We’ve often been told that we should “set a good example for others to follow.”  That’s usually said in the context of how we behave.  However, it can also apply to how we communicate as well.

SQL Saturday #716, NYC Schedule

The schedule for SQL Saturday #716 is out, and it turns out that I’m on it not once, but twice!

I will be doing the following two presentations:

• I lost my job!  Now what?!?  This is my career and job-hunt presentation, and it’s becoming one of my best sellers.
• So you want to be a SQL Saturday speaker?  This is a brand-new presentation that will be making its debut!

Hope to see you in the Big Apple on May 19!

Suppose you gave a presentation, and nobody came?

“When life gives you lemons, make lemonade.”
— unknown

“S**t happens.”
— unknown (or Forrest Gump — take your pick)

An article by my friend, Greg Moore, reminded me of a SQL Saturday presentation that I was supposed to do in Philadelphia last year.  It was one of the first sessions that afternoon, right after the lunch break.

My total attendance for my presentation: zero.

I don’t remember how long I waited for people — anyone, really — to show up; it might have been about ten or fifteen minutes before I packed up my laptop and left the room.  I was disappointed and even a little hurt.  How is it that I drive four hours to give a presentation, and nobody shows up?  At the same time, I also tried not to take it personally.  I posted my experience to my Facebook page to get it out of my system, I pretty much said “stuff happens,” and I shrugged it off.

I found out later that a large number of attendees — I don’t know how many, but I’ll guess about half — left the conference right after lunch.

(For what it’s worth, I actually gave two presentations that day.  My morning presentation was well-attended, and went very well.)

I also did a presentation at my hometown SQL Saturday last year.  Unlike Philadelphia, people did show up — there were five people, not including myself, in the room.  But for all intents and purposes, the room might as well have been empty.

Those of you who know me or who’ve seen my presentations know that I do my best to get my audience engaged.  I’ll ask questions, I’ll ask for volunteers, and I’ll ask for feedback.  I don’t like to lecture — that is, talk at an audience.  My preferred modus operandi for teaching is to have a discussion where I act as a facilitator.  I want to make sure that I’m making my audience’s time worthwhile.

However, this was problematic at this particular presentation.  These people were the five most introverted people I’ve ever had for an audience.  They barely responded at all.  During my presentation, the only acknowledgement I saw were a few barely discernible nods.  I had to force someone to volunteer for my demo (and she did not even come to the front of the room).  Trying to get these people to respond in any way, shape, or form was like pulling teeth.  Despite asking if anyone had questions, the only questions I got was from the event photographer — who was a friend of mine — going from room to room taking pictures.  (He saw my dilemma and decided to speak up.  After my presentation, I flagged him down and said to him, where the hell were you earlier?!?)

I won’t lie.  I was very disappointed with my audience in that presentation.  There might have been five people in the audience, but for what it’s worth, I might as well have been talking to an empty room.

Greg cites an article by Catherine Wilhelmsen where she talks about a similar experience.  (Her article is a great read; go check it out!)  As it’s often been said, s**t happens.  Failures happen.  Sometimes, all you can do is take your lumps, shake it off, and move on.

(Speaking of which, check out my previous article where I talk about screwing up not necessarily being a bad thing.)

I used to teach part-time at a local business school (roughly at the community college level).  Every now and then, my students would show up late.  (That’s where I learned that the ten minute rule applied to teachers, too.)  More often than not, however, my students did eventually show up.

I often joke that if I hold a class, a presentation, or a lecture where nobody shows up, I’ll start talking to the empty room — and see if anyone notices.  Some people have told me in reply that it’s an opportunity to practice your presentation.

Sometimes, things happen that are beyond your control.  Often, your first instinct is to be disappointed and take it personally (at least I know mine is).  Whenever such an event occurs, ask yourself if you could’ve done anything differently to avert the situation.  If the answer is yes, then learn from it and remember it for the next time.  But if the answer is no, then there’s nothing you can really do.  In either case, just shrug it off, move on, and try again next time.

The art of talking technology to non-technical people

“Eschew obfuscation.”
— unknown

Let’s discuss how to tie a tie.  First, you take the tie and put it around your neck, making sure that it lies within your shirt collar.  Make sure the seam is facing toward your body, and the wider end of the tie hangs down roughly two-thirds of the length of the tie.  In other words, the wider end should hang down farther than the narrower end.  Take the larger end over the narrower end.  Wrap it around once so that it forms a knot.  Take the larger end and put it through the knot you created.  Once that’s done, pull it tight.  Adjust your tie by pulling on the narrow end, which should now be behind the wide end.  Your tie should now appear neat and flush against your shirt.

Raise your hand if you actually followed the above paragraph.  And when I say “followed,” I mean that you read (as opposed to skimmed) through the entire paragraph, following every step and not falling asleep while reading it.  I’ll bet that not a lot of hands are up.

Yet this is exactly the way that so many technologists tend to write when they are asked to convey a set of instructions.  They will write (or talk) in lengthy detail, explaining every little thing and believing that the reader (or listener) is soaking up every detail and is in rapt fascination of the subject, holding on to every single word.

Oh, if only that was true.  If that was the case, we wouldn’t have technical writers.

I wrote a couple of articles a while back about tech writing frustration and why design matters.  They provide some thoughts that are directly related to this article, so I suggest you read them before continuing with this article.  If you haven’t read them yet, check them out.  Go ahead.  I’ll wait.

At this point, I’m trusting that you understand at least some of the principles behind good writing and design.  (If you don’t, and you didn’t read those previous articles, shame on you.)  Many, if not all, of them come into play when talking about talking to a non-technical audience.

Giving (and taking) instructions is hard

Let’s talk about that initial tie instruction paragraph for a moment.

This is a demo I use in two of my presentations.  I ask for a volunteer, preferably someone who does not know how to tie a tie.  I hand him or her a tie, and give that person simple instructions: “put it on.”  Of course, if the person doesn’t know how to put on a tie, he or she is likely to struggle doing so.

At that point, I get the rest of the audience involved.  My instructions to the rest of the group: “you folks are the help desk.  Tell this person how to put on the tie!”

I’ve done this demo to varying degrees of success.  In some cases, the audience does a very good job of explaining how to tie the tie, and it ends up looking pretty good.  I’ve also seen demos where my volunteer looks like he or she tried to tie the tie using only one hand, two fingers, and blindfolded.

The point of this exercise is to demonstrate that giving and receiving direction is difficult.  A lot of people mock tech writers, thinking that writing step-by-step instructions is no big deal.  But after putting people through this exercise, they usually end up singing a different tune.

Be patient!

When you’re talking to a non-technical audience, patience is a vital virtue.  People can be intimidated by technology, and lack of patience on your part will only do more to add to their discomfort.  Bear in mind that your audience is not as tech-savvy as you are, and will likely not have a grasp of technological concepts.

Any time you try to do a task you’ve never done before, how do you feel?  Most likely, you’re going to be at least a little nervous.  These people are likely to feel the same way.  Telling them to “click Enter” might as well be telling them to hit the gas pedal while they’re blindfolded.

Speaking of clicking Enter, don’t take for granted that people might not know what some technologies are.  I’ve heard stories of people using mice to different degrees, including using them as foot pedals and holding them up to the screen.  (And by the way, I’m sure you’ve heard the joke about not being able to find the “any” key.  I can tell you from firsthand experience that those are not jokes — the stories are true!)

What you see may not be what the audience sees

I’m sure you’ve seen the classic image below.

What did you see first: a vase or two faces?  Perspectives matter, and it happens all the time when trying to explain technical concepts.  Don’t assume that your audience sees the same thing that you are.  Even if you and your audience are looking at the same screen, what you and your audience see might not be the same thing.

Having said that…

A picture is worth a thousand words.

Very early in my professional career, I was tasked with writing a document for the nighttime support staff, explaining how to support a WORM drive.  When a customer requested data from an optical platter that was not in the drive, the user needed to insert the new platter into the drive.  I could have written an instruction saying that the A side had to be up, with the A label on the left edge, and the disk slide facing away from you as you put it in the drive.

Instead, I opened my very primitive paint program and drew something similar to this:

Suddenly, the instructions were clear.  The document was successful, and the operators were able to follow it to perfection.

However, be careful — there is a wrong way to use illustrations!  Imagine, for example, that you’re trying to find a Little Caesar’s Pizza or a Home Depot.  You find a site that has a map.  The problem is, the map is an image that’s zoomed in (with no way to expand the map).  The image looks like this:

Tell me, on what street are these places?  For that matter, in what city, state, or even country are these located?  There’s no way to tell, because there is absolutely no point of reference or context to this illustration.  A picture might be worth a thousand words, but if you’re not careful, it could be worth exactly zero words.

Use analogies

I once sat in on a SQL Saturday presentation by Thomas Grohser where he was talking about SQL data storage systems and data access.  I’ll admit that I had a hard time following some of what he was saying, until he gave the following analogy:

“Imagine you get on an elevator with ten people.  Each person presses a different button.  Now imagine that the elevator has to go to every floor in the order that the buttons were pushed!”

Suddenly, Thomas’s concept was crystal clear!

Another time, I was speaking to a co-worker who had tried to explain to someone that she was trying to store more data on a disk than there was space on the disk.  (This person did not understand that data takes up disk space.)  I told him, “you should’ve said that you can’t put ten pounds of stuff* into a five pound bag!”

(*Okay, I didn’t say “stuff!”)

The moral of the story is that analogies are highly effective in communicating concepts.  If you can effectively explain a concept using an analogy (note: make sure the analogy you’re using is business-appropriate), then go ahead and do so.

KISS!  KISS!  KISS!!!

No, I don’t mean hanging out with your sweetheart.

Make sure you follow the KISS principle: KEEP IT SIMPLE, STUPID!

Technical instructions need to be kept simple.  A lot of technologists don’t understand that reading is work!  It takes work to read and comprehend a paragraph.  What if a set of instructions needs to be understood quickly?  If a person needs to take a minute to figure out what is being said, that’s a minute that was just wasted.

Generally, the rule of thumb I use is, if it takes more than a few seconds for a reader to understand my instruction, then my instruction has failed.  Don’t make the reader have to work.

Realize that this will not happen overnight

Now that I’ve gone through some of the suggestions for talking to non-technical people, understand that not everyone has the ability to convey technical information in a manner that can be understood, and being able to do so won’t happen overnight.  Like everything else, it takes time and practice to get that skill down.

In any case, hopefully, these tips will help you become a better technical communicator.  In the long run, this ability will enhance your skill set — not just as a communicator, but as a technologist as well.

What to expect at a SQL Saturday

Those of you who follow my ‘blog know that I post a lot about SQL Saturday.  I attended my first SQL Saturday in New York City in 2010, and had a great time.  I’ve attended SQL Saturday events every year since, and my involvement has grown, first when my hometown SQL user group started hosting our own SQL Saturday events, then again in 2015 when I first started speaking with my own presentations.

For the benefit of those of you who have no idea as to what SQL Saturday is, here’s a primer.  SQL Saturday is a technical conference that takes place on (mainly) Saturdays at various locations (despite the name, SQL Saturday does not necessarily have to take place on Saturday).  As the name implies, these conferences revolve primarily around technologies related to Microsoft SQL Server.  However, while SQL Server is the primary focus for these conferences, not all presentations focus on SQL Server.  Some presentations may be of interest to developers, other data professionals, and people who just want to learn more about data technologies or technological trends in general.  Some presentation topics don’t focus on technology at all; SQL Saturday includes a professional development track where presentations focus on various professional soft skills, including (but not limited to) non-technical business skills, business-related social skills, networking, career, job hunt, communication, and so on.

My friend, Ed Pollack, wrote an article about happens at a SQL Saturday.  It’s a great read, and I highly recommend it.

So for people who might be interested in attending a SQL Saturday, I put together this primer (in a FAQ format) based on my own experience with SQL Saturday.  Hopefully, this will answer your questions as to what SQL Saturday is about, as well as whet your appetite for attending these conferences!

If this article doesn’t answer your questions, feel free to comment!

Who can go to a SQL Saturday?

Short answer: anyone!

Longer answer: anyone who has an interest in databases, data science, analytics, business intelligence, statistics, technology, development, career and professional development, or even if you just want to network with professionals in technology.  Not only is SQL Saturday a wonderful opportunity for free training, it’s a fun social event where you can meet people in the field.

Most SQL Saturday events do require you to register, since space is often limited (also, some locations are secure facilities, which require pre-registration).  Register on the individual location website for the event that you want to attend; these links can be found at sqlsaturday.com.

I know nothing about technology, or I am not a technical professional.  Can I go to SQL Saturday?

Yes!  See my answer above.  You do not need to be a professional to attend.  If you have an interest in anything related to data, you’re encouraged to show up.  And because the event is free, it’s ideal for students.

Did you say free?  How much does it cost to attend a SQL Saturday?

Yep, that’s correct.  SQL Saturday is free to attend.  Most events charge a nominal fee for lunch; that amount varies with the event.  It’s usually in the ballpark of around $10 to $15 (US).

So who pays for all this?

Sponsors cover the costs for these events.

What about this fee for a precon?  What is a precon?

A precon is a daylong presentation on an individual data topic (topics vary).  These precons generally take place the day before SQL Saturday.  Unlike the main SQL Saturday  event itself, there is a fee to attend a precon, usually in the ballpark of $150 to $200, depending on the topic.

Do I need to know anything about SQL to attend a SQL Saturday?

Nope!  SQL Saturday welcomes people of all technical levels, even if you don’t know anything about databases.  Some events even include a beginner track that offer introductory topics for SQL and database newbies.

What topics are presented?

It varies, depending on the event.  Different events can have different subject tracks.  Also, because these events have different speakers, presentation topics vary as well.  Most topics revolve around SQL Server, but application, administrative, and professional development topics are offered as well.

How much do SQL Saturday speakers and staff get paid?

Zero.  Nada.  Zilch.  SQL Saturday is an all-volunteer event.  When I apply to speak at SQL Saturday events, I do so knowing that I’ll do this on my own dime.  Distance from home, transportation costs, lodging, food, and schedules all factor into my planning whenever I apply to speak at a SQL Saturday.

How should I dress for a SQL Saturday?

SQL Saturday tends to be a casual event.  I’ve worn t-shirts, jeans, summer shorts, sandals, Hawaiian shirts, baseball jerseys, and baseball caps to these events (not necessarily all at the same time).  Heck, I even remember a SQL Saturday where Grant Fritchey wore a kilt.  (No, I have no idea if he wore it in the “traditional” Scottish style, and I didn’t ask.)

I’ve often seen job seekers attend SQL Saturday dressed in full suits.  While suits can be worn at these events, be advised that you will likely stick out like a sore thumb.  Additionally, note that SQL Saturday is an all-day event, and a suit might not be comfortable for an entire day, especially if it takes place in the middle of the summer!

My advice: dress comfortably, and however you think is appropriate.  If you feel a need to dress up to impress potential employers, I would recommend slacks and a decent shirt (if you’re a guy, that is; I’ll admit that I don’t know what the female equivalent would be).  A tie and jacket are optional.  You don’t need a full suit.

I want to be a SQL Saturday speaker.  How can I get started?

You can start by reading my previous article that talks about how I got into it.  Additionally, I have a presentation that talks about becoming a SQL Saturday speaker (this is a brand new presentation that will make its debut at SQL Saturday #716, New York City!).  There are also a number of other presentations about becoming a speaker as well; go check them out!

I have more questions.  How can I get them answered?

Did I not answer your question?  For starters, you can leave me a comment, and I will answer your question as best as I can!

I also recommend SQL Saturday’s website.

There are also a number of articles that discuss what to expect at SQL Saturday.  I highly recommend Ed’s article, for starters.