Month: May 2018

Memorial Day Murph

A few of us in the office were discussing plans for the upcoming Memorial Day weekend.  I mentioned that I was doing this thing on Monday called Memorial Day Murph (those of you who CrossFit know what I’m talking about).  I tried to describe the workout, and I couldn’t remember the movements and rep scheme, so I looked it up.  In doing so, I came across this article that talks about “surviving” Memorial Day Murph.

First, I want to talk a little about the article.  Doing Murph as prescribed (“Rx’ed,” in CrossFit parlance) is not for the faint of heart (literally — it’s a pretty intense cardio workout).  I generally make it a point to make sure I’m hydrated (I do this, anyway) and to make sure that I’ve had something to eat before I attack it.  I also make sure that I scale.  I am not in the class of Mat Fraser, and likely never will be.  (When I was a kid, I had a dream of playing for the Yankees, too.  You probably can tell where that went.  But I digress.)  I have yet to run a full mile; I have enough trouble running a fraction of that.  I don’t remember how I scaled it last year; I might have done something like an 800m run (admittedly, I usually end up walking a good chunk of it), ring-rows instead of pull-ups (I still can’t do a pull-up to save my life — I’m working on it), and a reduced number of push-ups and squats.  Nevertheless, even scaled down, it still makes for a pretty serious workout.  But I will say that if a longtime self-admitted couch potato like me can do it, so can you.

I also want to talk about the spirit of “Murph.”  Murph is what CrossFitters refer to as a “hero WOD” — that is, a WOD (Workout Of the Day) that is named for and to honor a hero — in this case, Navy Lieutenant Michael Murphy, who was killed in Afghanistan in 2005.  (Memorial Day Murph was even made into a fundraiser.)  Hero WODs tend to be intense — moreso than the typical CrossFit WOD.  Every Memorial Day, CrossFitters around the country do Murph in the spirit and honor of this fine man who died for his country.  It is a way for CrossFit athletes to honor this hero, but it’s also a reminder as to what Memorial Day is about.

And, of course, Memorial Day is known as the unofficial start of summer, and is usually accompanied by barbecue, burgers, hot dogs, and beer.  My CrossFit gym is no different; Memorial Day Murph is followed by a cookout, along with plenty of camaraderie.  Our gym members are a close-knit group, and I’m sure other CrossFit gyms are similar.

So, I’ll be spending my upcoming Memorial Day holiday hanging out with a bunch of CrossFit athletes while trying not to exhaust myself from a regimen of running, pull-ups (likely ring-rows for me), push-ups, and squats.  And a good time will be had by all.

Advertisement

Definitions that aren’t

This is yet another item that can be listed under tech writing frustrations.

I was working on a project where we needed to rewrite a set of glossary definitions.  I won’t go into the definitions (primarily due to corporate privacy), but for illustration purposes, let me use this analogy.

Let’s say you’re looking up a definition for, say, a car.  You come across the following glossary listing: “A car has four wheels.  It is made of metal.  It is not a boat.”

This tells you about some of a car’s attributes (four wheels, made of metal) and what it isn’t (a boat).  It never tells you, in any way, shape, or form, what a car actually is!

Yet this horrifically-written glossary is entirely made up of “definitions” (and I use the word loosely) written just like this.  I don’t know about you, but my assessment of these glossary definitions would be “totally useless.”

I come across “definitions” like this more often than I want to say, and they make me cringe.  People look up word meanings to find out what words mean.  Writing a “definition” that describes only its attributes is useless.  If a glossary “definition” does not “define” what it is, then it does not do its job.

Birth of a user group

At SQL Saturday in New York City yesterday, I debuted a brand-new presentation: So you want to be a SQL Saturday speaker?  Although only two people showed up, they were very receptive and engaging, which is exactly what I want out of my presentations.  As someone once said, the size of the audience doesn’t matter; just play your best.

What I found fascinating, however, was the interaction between the two gentlemen.  Both were from Long Island.  They traded contact information, and started discussing the idea of creating a SQL user group around there.

It brought to mind a memory from eight years earlier.  It was in 2010.  I was traveling down to New York for my very first SQL Saturday.  I had exchanged messages with someone on a SQLServerCentral.com forum about the conference; he was also coming from the Albany area, and was attending the same conference.  We met on the train, we talked, and we discussed the idea of creating a user group in the Albany area.

The gentleman was Dan Bowlin.  Our forum conversation from eight years ago is still on SSC, and can be found here.  We became friends, and we still remain friends to this day (although Dan no longer lives in the Albany area; he took a job down in Connecticut a couple of years ago).  The group we ended up founding is now CASSUG (Capital Area SQL Server User Group).  We didn’t know what we were getting into with our initial foray into this endavor, but CASSUG now has a few hundred members, holds meetings every month, and hosts its own SQL Saturday (our next one is coming up in July).  From a simple beginning, a user group was born!

I’ve written before about the benefits of user groups.  I’m hoping that this dialog between these two gentlemen leads to the creation of another one.  And I hope to hear about meetings for the Long Island SQL Server User Group (LISSUG) sometime soon!

Maybe they’ll even invite me down as a guest speaker sometime!

Ten Years at Redgate

Congratulations to my friend, Steve Jones, for ten years at Redgate!

Voice of the DBA

This year was my 10th anniversary of working for Redgate. The actual date was a bit ago, but they held off my celebration until I came over. These are nice at Redgate, better than at some companies where I’ve seen someone in management just give a mention during a company meeting and a token gift. At Redgate we get a really nice gift, which was a Garmin Forerunner 645 for me.

IMG_20180517_125604

At Redgate, the CEO comes around and does a 5-10 minute speech on the person, with some of his thoughts and memories, and also shares some stories that others in the company have sent in. There is usually a few embarrassing notes, and in my case, I got this picture, which is likely one that everyone thought would generate the most red from me. It didn’t, though I don’t think there are any really embarrassing pictures or video for…

View original post 725 more words

On deck: SQL Saturday #716, NYC

Reminder: I am speaking at SQL Saturday #716, New York City this coming Saturday, May 19!  The conference will be at the Microsoft Technology Center, directly across 8th Avenue from the Port Authority Bus Terminal.  This is a secure location, so you must register using the link above if you want to attend!

I will be giving the following two presentations:

  • I lost my job!  Now what?!?  This is my career/job hunt presentation, and it’s becoming one of my best-sellers.  In this talk, I provide tips and advice for surviving a jobless situation.  Anyone who is looking for new employment is encouraged to attend!
  • So you want to be a SQL Saturday speaker?  This is a brand-new presentation that is making its debut at NYC SQL Saturday!  Want to be a speaker at SQL Saturday?  Here’s how I did it — and you can, too!

Hope to see you there!

Upcoming speaking engagements

Here are my most recent speaking engagement calendar updates, as of today!

Confirmed

I am confirmed to be speaking at the following.

Submitted, but not confirmed

I’ve submitted presentations to these events, but I don’t yet know whether or not I’m speaking.

  • Saturday, July 28: SQL Saturday #741, Albany, NY — my hometown SQL Saturday!  I won’t know until June whether or not I’m picked to speak, but I will be there, regardless of whether I’m presenting or not!
  • Saturday, September 29: SQL Saturday #770, Pittsburgh, PA — I should find out sometime around August as to whether or not I’m presenting.

Save the date

These events are not yet official.  Once they are, I hope to submit to them.

  • Saturday, September 22: SQL Saturday, Boston, MA
  • Saturday, December 15: SQL Saturday, Washington, DC

Keeping it simple: it can get complicated

“Everything should be made as simple as possible, but not simpler.”
— Albert Einstein

“If you can’t explain it to a six year old, you don’t understand it yourself.”
— also supposedly by Albert Einstein

If you’re on Facebook, I’m sure that you’ve seen the memes that go something like this: “tell a sad/scary/happy (whatever) story using only four words.”  It’s hard to do, isn’t it?

Welcome to the world of technical communication.  One communication tenet that I constantly preach — and you’ll hear me talk about this time and again in my presentations — is the KISS principle: “Keep It Simple, Stupid.”  Ask anyone involved with technical writing, documentation, or professional communication, and I’ll bet that most, if not all, of them will mention the KISS principle in some way, shape, or form (maybe not in those exact words, but you get the idea).  The goal of communication, after all, is to transmit information from a sender to a receiver.  If the message being conveyed is easy enough for the receiver to understand, so much the better.

However, here’s the irony: making things simple is difficult!

How often have you been asked to write something for knowledge transfer, and ended up with something that was nearly incomprehensible?  (Don’t be afraid to admit it; hey, I’ve done that, too!)  Whenever we’re tasked with writing documentation, our tendency is to explain every little tidbit of knowledge that’s in our head.  When that happens, we end up writing a huge paragraph of black text that nobody — and I mean, NOBODY, including yourself — wants to read!  That is not conveying information; that is obfuscation.

So how do we go about making things simpler?  For starters, I discuss some ideas in my previous articles about design, document frustration, using examples, and talking to non-technical people.  I won’t rehash them here; I’ll leave it to you to go back to read those articles.

Additionally, here are some more thoughts that might be helpful.

  • Include only information necessary for the task at hand.  Avoid the tendency to include every last detail.  As a former manager was once fond of telling me, “don’t tell me how to build the clock; just tell me what time it is!”  I also remember a time back when my father was first learning about PCs.  He kept asking me questions about how the CPU and memory worked.  I finally said in frustration, “you don’t have to know how an internal combustion engine works in order to drive a car!”
  • Put yourself in the reader’s shoes.  When I wrote one of my very first technical documents, I said to myself, “okay, let’s say I’m the night operator who needs to use this document.  What do I want to see that would help me?”  That mindset resulted in a very successful document.  Reader empathy goes a long way.
  • I’ve said it before, and it’s an old but true saying: a picture is worth a thousand words.  A good illustration can convey a concept that’s difficult to do in words.
  • Avoid using long (or multiple) words when a simple (or single) word will do.  I think this is self-explanatory.
  • Voice matters.  Below are two sentences, one using active voice and one using passive voice.  Question: which one is easier to read?  Advice: try sticking to active voice.
    • Active: “John mowed the lawn.”
    • Passive: “The lawn was mowed by John.”
  • Formatting is a big deal.  Check out documents that you found easy to follow.  Pay particular attention to paragraph length, whitespace, headings, and so on.

People — myself included — say that the easier you can make things, the better.  The fact is, we humans only have a limited attention span, and we neither have the time nor the patience to comprehend complex information.  Simplifying things helps — but it’s also hard to do.  If you ever believe you know a lot about a concept, try explaining it to a child — and see for yourself how easy it is.