SQL Saturday #741, Albany, NY, July 28 — the schedule is out

The schedule for SQL Saturday #741 in Albany is out!  (My presentation is scheduled for the first session of the morning.  Ugh!)

I will be doing a brand-new presentation (so new, in fact, that as of this article, my presentation slides are not yet finished!).

My new presentation is titled: “Networking: it isn’t just for breakfast anymore.”  It is based on my ‘blog article of the same name.  We will discuss networking, what it is, and why it’s important.  We’ll discuss where and how to network, and ways you can break the ice.  We’ll even have an opportunity to network within the confines of our room.  (I suppose an alternate presentation title could be, “Networking for beginners.”)

If you’re looking for networking opportunities or looking for ways to improve upon your networking skills, come check out my session!  Click this link to register for SQL Saturday #741, and join us in Albany, NY on Saturday, July 28!

See you there!


Better Comments

This is a reblog of a post by my friend, Steve Jones. I’ve often said that commenting code is a form of documentation, and needs to be done more.

Voice of the DBA

I assume most of your comment your code.

Well, you probably comment code most of the time.

I’d bet your comments have quite a bit of detail.

And you do this completely inconsistently.

That’s what I’d think, or maybe just what I want. Even the best developers I know will not consistently comment code. You can drift through any project on Github and see this. Those projects on GitHub might even be better documented because people know they are public. In most corporate environments I have worked in, I’ll find that when people get busy, or distracted, or even when they’re experimenting to find a solution, and they don’t write detailed comments. Usually only when someone fixes a bug, with a solution found quickly, do I get a really useful comment.

There are all sorts of ways that people think about commenting their code. I ran across a post from…

View original post 254 more words

Always ask someone to test your product

This morning, one of my colleagues posted this message to our Slack channel:

please ask someone else to test your code before pushing it

It brought to mind an important thought (and more ‘blog article fodder): any time you produce something, regardless of what it is — a software application, documentation, a presentation, a music composition, a dish you cooked, etc. — always ask someone else to test it out before you send it out for public consumption.

That testing could take several different forms — it could be an end user trying your application, somebody reading your document, listening to your presentation or your music, trying your dish, and so on.  Testing results in feedback, which results in improvements to your product.

Whenever we produce something, we have our own vision — and our own biases — as to how the product should come out.  We expect our products to be perfect as resulting from our own visions, and we expect (and demand) that the consumers adhere to our visions and how we expect the products to be viewed or interpreted.

Unfortunately, we are blinded by our biases.  The world does not share our same visions.  People who use our products will never, ever, perfectly interpret how our products should be consumed.  More often than not, we’ll find that what we produce will be used or interpreted in ways that never occurred to us.

Even in my own workplace, I write and edit a lot of online documentation.  Much of what I write comes from other sources, often about topics about which I know little (or, sometimes, nothing).  I try to write material based on the information I have at hand.  Very often, I come across gaps that need to be filled.  I’ll do my best to ask original authors what was intended, or to dig for information to fill those gaps.  But in absence of those resources, I end up making assumptions and using my own intuition to fill in the blanks.  Those assumptions might not necessarily be correct, and what I write could end up being different from what was originally intended.  It is for this reason why I am constantly asking my colleagues, “take a look at what I wrote.  I want to make sure what I wrote is accurate.”

In a manner of speaking, creating products is a form of communication — in that what we produce results from an idea in our heads, and the end users — the consumers — are the ones “listening” to the communication — in this case, the end product.  If you are familiar with the basic communication model, a sender creates a message, a receiver interprets the message, and the receiver reacts to the message in the form of feedback.  Producing a products works in exactly the same way — a producer creates a product, a consumer uses the product, and the consumer reacts to the product, generating feedback.  In between the sender and the receiver is “noise” that degrades the message or the product (it is not literally noise — the “noise” can simply be the fact that the sender’s and receiver’s interpretation of the message are not one and the same).

So, any time you create some kind of product, always ask someone else to try it out.  You’ll find that the person’s feedback will result in tweaks to your product.  And you will end up with a better product.

Humble beginnings

Once again, the Facebook “On This Day” memory feature shows it can be a curious thing.  And again, this is one I wanted to share.

The picture you see above showed up on my Facebook memories feed this morning.  Three years ago today, I gave a presentation at my local SQL Server user group meeting.  I had come up with a presentation idea that I thought would be of interest to my user group, as well as other technical professionals.  I jotted down some notes, put it into a presentation, and presented it at my local user group.

About a month later, I gave this very same presentation at our local SQL Saturday.  It was my first SQL Saturday presentation!

I was curious as to how other events would take to my presentation.  Later that year, I submitted it to, and was accepted at, another SQL Saturday.  It was my second time speaking at SQL Saturday, my first time speaking at an event in “foreign territory,” and my first SQL Saturday — speaking or attending — outside of New York State.

Since that humble beginning, I’ve spoken at 13 (soon to be 14) SQL Saturdays at seven different cities around the northeastern United States.  Thanks to this endeavor, I’ve traveled around the region, met a lot of great people, expanded my professional profile, started a ‘blog (that you’re reading right now!), enhanced my career, gained more confidence, improved my presentation skills, and become a better person.  This all came about because of these conferences and from this simple start three years ago.

I hope I’ll be doing many more!  Happy three year anniversary to me!

My hometown SQL Saturday: I’m speaking, July 28

I just got the official word that I will be speaking at my hometown SQL Saturday.

As of right now, I don’t know which presentation(s) I’m doing; I only know that I am speaking!

Come join us at UAlbany on July 28!  Go the link above to register, and mark your calendars!

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.

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.