Looking Back

This is a reblog of a post from my friend, Steve Jones. He touches on a topic that is near and dear to my heart, and one that I strongly believe is crucially important.

Nearly all of my SQL Saturday presentations have revolved around documentation and technical communication. Technology may have changed over the years, but the importance of documentation has not. I strongly believe that documentation is getting to the point where it is being dangerously ignored, something that we, as technical professionals, cannot afford to do.

Voice of the DBA

Someone sent me this post on 40 years of programming. It’s a read that laments a few things and complains about many others. Most of the thoughts are opinions, and as such, you may or may not see validity in them. I suspect most of you, like me, see some things are mostly true and some as just false. Since I’ve been in this business for nearly 30 years, many of the comments bring back memories and thoughts about my career as well.

One of the things I do lament is the declining quality of documentation. I’ve seen the volume and detail decline over the years. I wouldn’t want to go back to paper, but I would like to see better examples and more complete examination of the ins and outs of the various functions and features. Far too often I find that there are examples, explanations, or behaviors…

View original post 398 more words

Advertisements

My hometown SQL Saturday: Albany, NY, July 29

My local SQL user group is hosting SQL Saturday on July 29, a week from this Saturday!

I will be speaking; I will be giving my presentation on documentation.  There are also a number of other presentations that people might find of interest.

When I attended SQL Saturday in New York City a couple of months ago, I sat in on Lisa Margerum’s session on networking.  It is an excellent session, and I recommend it highly.

A number of my friends are also presenting, including Greg Moore, Thomas Grohser, George Walters, John Miner, and Ed Pollack.  They always give good presentations, and I recommend them highly.  Check out the schedule for more details.

Hope to see you there!

 

SQL Saturday #638, Philadelphia

This coming Saturday, June 3, I will be speaking at SQL Saturday #638, Philadelphia (okay, it’s actually in a town called Whitpain Township, not Philadelphia, but that’s what they call the event, so…)!

I will be giving the following two presentations:

  • Tech Writing for Techies: A Primer — Documentation is one of the most critical, yet most blatantly ignored and disrespected tasks when it comes to technology. Businesses and technical professionals ignore documentation at their own risk. This session discusses what tech writing and documentation is about and why it’s critical for business. It also explores possible reasons for why it’s ignored, how documentation can be improved, and how “non-writers” can contribute to the process.
  • Disaster Documents: The role of documentation in disaster recovery — I was an employee of a company that had an office in the World Trade Center on Sept. 11, 2001. Prior to that infamous date, I had written several departmental documents that ended up being critical to our recovery. In this presentation, I provide a narrative of what happened in the weeks following 9/11, and how documentation played a role in getting the organization back on its feet.

    While other disaster recovery presentations talk about strategies, plans, and techniques, this presentation focuses on the documentation itself. We will discuss the documents we had and how they were used in our recovery. We will also discuss what documents we didn’t have, and how they could have made the process better.

Hope to see you there!

The checklist manifesto

Some time ago, I came up with a new presentation idea that I tentatively titled “The magic of checklists.”  The idea is to demonstrate how checklists can improve tasks in any organization.  I have a number of ideas regarding this presentation, and I’ll expand upon them in a future ‘blog article.

As preparation for this idea, I assigned myself some homework.  My friend, Greg Moore, recommended a book to read: The Checklist Manifesto by Atul Gawande.  I borrowed a copy from the local library and started reading.

The book (which I’m still reading) is turning out to be an excellent read: so much so that I’m considering purchasing my own copy, instead of just relying on the one I borrowed from the library.  (This way, I can use a highlighter and scribble my own notes in the book.). Yes, it reinforces my ideas about using a checklist to improve upon workplace tasks.  But I’m also discovering that there is so much more.  Reading this book has enlightened me on numerous ideas that had never occurred to me.

The book hits upon numerous concepts, each of which is worth an entire presentation in their own right.  Among them: the importance of communication, organizational structure, teamwork, crew/team resource management, keeping an open mind, empowering a team, following instructions, making adjustments, and doing the right thing.  (Since I’m not yet finished with the book, there are likely a number of other concepts I haven’t mentioned that I haven’t yet come across.). When I first picked up the book, my initial thought was, “how much can there be about a simple checklist?”  I’ve since learned that a checklist — any checklist, no matter how small — is not simple.  And while a checklist is an important tool, it is also a big part of an even bigger process.  All the ideas I listed several sentences ago are all part of that process.

I’d like to relay a story I came upon in the book.  David Lee Roth of Van Halen was famously known for canceling concerts if his instructions for leaving a bowl of M&Ms with the brown ones removed in the dressing room were not followed.  Many people — myself included — decried him for these seemingly cockamamie instructions.  However, there was a method to his madness.  It turned out that this was a test.  If that instruction hadn’t been followed, then it was possible that another critical instruction — like, say, installing bracing to ensure the stage didn’t collapse — had not been followed.  (And before you think instructions like these can’t be missed, they can, and they have — sometimes, with disastrous consequences.) It goes to show that there is always more to the story.

Once I finish reading this book and can organize my thoughts, I’ll put out another article and another presentation (hopefully, coming soon to a SQL Saturday near you).  In the meantime, I highly recommend this book.  Maybe it’ll change your perspective the way it has changed mine.

SQL Saturday #545, Pittsburgh

I’ll be speaking in Pittsburgh this Saturday, October 1.  Hope to see you there!

Memories of 9/11

(Photo image courtesy of Wikipedia)

I still remember the morning of September 11, 2001 (15 years ago today) like it was yesterday.  It was an ordinary Tuesday morning.  At the time, I lived in a townhouse in Clifton Park, about 15 miles north of Albany.  I got up, showered, got dressed, kissed my then-girlfriend (now wife) good day, stopped at the local convenience store to pick up the day’s New York Times, and drove to work.

My company had an office in the World Trade Center.  Although I was based out of the Albany, NY office, I regularly made business trips to the World Trade Center roughly about once every couple of months; in fact, I had been in the World Trade Center only a couple of weeks earlier.  I had been down there often enough to become well-acquainted with the area; I knew the hotels (including a Marriott right between the two towers) where I regularly stayed on business, I knew some of the restaurants in the area, I’d become familiar with the subway lines that went in and out of the area, and I’d become accustomed to taking walks in Battery Park.  While I am a lifelong upstate New Yorker and not an actual resident of New York City, I’d been to the City often enough that, to me, it felt like a second home.

Likewise, I knew the thirtieth floor of Tower 1 — where one of our offices was located — very well.  One of our large data centers, a server room (in which I spent a lot of time when I was there), was on that floor.  I made sure our server room maps and information were up-to-date.  I had come up with a map grid system (identical to the letter-number grid combinations that you’d find on road maps) to identify and label server racks.  Whenever we added a new server rack, I’d create a label for it, record the servers within the rack, and make sure it was updated on the map.  Years later, I would eventually come up with an online system, including a SQL Server database back-end, that automated most of the data that I gathered from my regular server surveys, but in those days before automation, I had to do the work manually.  No matter.  I enjoyed working in the World Trade Center, and I always looked forward to my excursions down to the southern tip of Manhattan.  Those trips always made the mundane work worthwhile.

At first, there was nothing out of the ordinary (from my perspective, anyway) when I arrived at the office in Albany and went upstairs to my desk.  Someone told me that a plane had hit the World Trade Center.  I didn’t think anything of it at first.  My first thought was that a small single-engine Cessna had hit one of the towers.  How tragic, I thought, and I told myself to check the web for any news about it later that morning.  I dropped off my briefcase and my newspaper at my desk — again, another normal, typical morning for me — went downstairs to the cafeteria to get myself some coffee and some breakfast, and went back upstairs to my desk.

At this point, the office was abuzz.  I checked a few news websites for information.  That’s when I discovered that the plane that had hit wasn’t a small private plane; it was a Boeing 767.

I called my house immediately.  I told my girlfriend, “turn on the TV right now!”

That’s the last of what I remember clearly from that day.  The rest of the day is a blur.  While my memory of the events from that point forward is hazy, this is what I remember.

No work was done for the rest of that day.

I made my way over to the help desk area where a TV was broadcasting the news.  Other than the news broadcast, the entire area was deathly silent.  I remember one girl on the help desk was sobbing.

My manager had gone down to the City that day; he was there every week.  I remember his wife calling me.  She was understandably in hysterics.  I told her that I had not heard anything from him (the lines were all jammed from the amount of cell traffic, so no calls were getting through), and I promised that I would give her a call once I’d heard any news.

(I did see my manager later that evening; he told me that as he approached the office, a crowd was heading in the other direction.  He was there to see the towers fall.)

I remember Dan Rather broadcasting the events.  I remember the stunned silence as we all watched the towers fall.

I had heard stories from my friends and co-workers who worked in the World Trade Center.  One person was downstairs getting breakfast.  He had only moments earlier gotten out of the elevator — when flames shot out of the elevator.  Another person ignored announcements to stay where they were, and escaped down the stairwell — a decision that likely saved his life.

The next few weeks were hectic.  Our department (we were responsible for supporting the company’s server infrastructure), including employees from New York City, Harrisburg, Syracuse, and Middletown, convened in the Albany office to come up with a recovery plan.  We started with rebuilding critical domain controller servers and went from there.

All that time that I had spent in the World Trade Center documenting the servers proved to be crucial.  Based on the data we had, we were able to recreate the servers we had lost and rebuilt the infrastructure.  We obtained backup data from offsite storage — proving the value of backing up your critical data and storing it offsite — and recovered much of the data stored on the lost servers.  We worked thirteen straight days around the clock, working in shifts.  A server engineer would rebuild a server; if it wasn’t finished by the end of his or her shift, another engineer coming on-shift picked up where the previous person left off.

Everyone wanted to do their part.  I remember one of our colleagues was away on vacation when the planes hit; he was unable to return immediately because all flights were grounded.  He eventually was able to make it back to contribute to the cause.  Even my own manager had to tell me to go home and get some sleep.  He knew I wanted to do my part, but he also knew that it was important for us to get our rest so we could contribute.

I was willing to give up my extracurricular activities to help out.  I was going to skip band practice to help rebuild.  No, I was told.  If you skip things like that, the terrorists win.  Stick to your normal routine.  It’s important that we maintain morale and keep our spirits up.  We were all encouraged to work and to rest when we had to.  Employees from out-of-town were encouraged to take trips home to spend time with their families, then return to Albany to continue with the work (we set up a schedule so that everyone could do so).  Any sense of normalcy and efforts to boost morale were evident.  The company even served us breakfast during those two weeks; I remember eating a lot of pancakes, eggs, sausage, and bacon when I got into the office each morning.

After two weeks, we had rebuilt enough of the server infrastructure that we were able to maintain our business.  We weren’t at 100%, but it was enough to keep it going.

It wasn’t until later that we discovered the aftermath in regards to our company.  We lost nine employees.  Among our lost employees were a man confined to a wheelchair and his friend who wouldn’t leave his side.  Every year, on September 11, I still think about those nine co-workers that I lost.  I didn’t really know them.  (Regarding the man in the wheelchair and his friend: I vaguely remember exchanging a couple of emails with them, and I think I spoke to one of them on the phone a couple of times, but I did not know them that well.)  Nevertheless, I still consider them as I would friends or family members that I lost.

Fifteen years have passed since that fateful day.  It is important for us to remember.  We can and must always remember the lessons of 9/11.  However, it is also important for us to continue with our lives.  Not moving on would be a great disservice to everyone who lost their lives on that tragic day.

Life goes on.

SQL Saturday #545, Pittsburgh

I got word yesterday that I will be speaking at SQL Saturday #545, Pittsburgh on October 1!  I will be giving my presentation, “Disaster Documents: the role of documentation in disaster recovery.”

Hope to see you there!