SQL Saturday #741 Albany — the debrief

Once again, we had another great SQL Saturday here in Albany this past weekend!  I don’t know how many people attended, but by my estimate, we had well over two-hundred people.  I had a great time (as usual), and it serves to remind me why this is one of my favorite events.

My own presentation went very well!  I had nine people attend my session.  Two people (not including myself) were in the room when I started, but more people started filing in after I began my presentation.  Everyone I spoke with told me it was a great presentation, and I got nothing but positive feedback!

I did, however, get one piece of feedback that I did not expect.  I spoke with a number of people who did not attend my presentation, and one who almost skipped it (but ended up coming, anyway).  They all told me the same thing: they read my presentation title and automatically assumed that my talk was about computer networking, not business networking.  Had they known that, they all told me, they would have been there.  So I missed out on a potentially larger audience, simply because of my presentation title.

My initial reaction was frustration.  Mt first thought was, “read the presentation abstract, people!”  I didn’t want to change it; I liked the title and thought it was clever (I’d taken it from one of my ‘blog articles with the same name).  At the same time, I also couldn’t ignore the feedback; it’s human nature to judge a book by its cover (or, in the case, the title), and first impressions are important.  So, reluctantly, I renamed my presentation.  At the same time, I also made a slight tweak to my presentation slides; I removed one slide that did not serve much purpose during my presentation.

I’d be remiss if I didn’t mention a great event without talking about other great presentations.  I attended James Serra‘s session on presenting.  I’m always looking to improve upon my own presentation skills, and I got a lot out of James’ presentation (as always).  Not only did I pick up a few new tips, he also reinforced some points that I use in my own presentations.  This is always good to hear; it legitimizes things that I discuss.  I also sat in on a less serious presentation by Thomas Grohser.  At the end of the day, a little humor is a good thing.  James and Thomas are both excellent speakers, and I always recommend them.  I’d also heard great things about a session I’d missed presented by my friend, Deborah Melkin, another wonderful speaker that I highly recommend.

Unfortunately, part of the reason why I missed Deborah’s session (and others) was an issue that needed my attention.  When I arrived at the event site that morning, one of my tires went flat.  I didn’t have the time to address it, and I didn’t feel much like dealing with it, especially on a warm and humid day.  Fortunately, I have a AAA membership.  Let me tell you about how handy that became that afternoon.

Of course, there were also the events around SQL Saturday.  Friday night was the speaker’s dinner.  It was held at a Mediterranean restaurant about ten minutes away from my office.  I’ve driven past this place many times, and had no idea that it was there.  It was a good place, and I’m going to keep it in mind!  The closing and accompanying raffles are always fun.  My wife’s name was actually drawn for a prize!  Unfortunately, she couldn’t claim it, simply because she was not there, and the rules stipulate that you need to be present to win!  (Some people said that I should claim it by proxy, but at the same time, rules are rules!)  The post-event party was held at a place across the street, a great opportunity to mix and mingle with fellow speakers and event volunteers in a loose and casual atmosphere!

All in all, it was a great event!  This is one of my favorite events, and I look forward to doing this again next year!

Advertisements

Don’t keep an idea to yourself

My friend Greg Moore recently commented on a Facebook post regarding our upcoming SQL Saturday (tomorrow!) in which he credited me for my idea about a forum about women in technology.  The idea had occurred to me when I saw that Rochester SQL Saturday was doing such a forum, and I suggested that we should do one as well.  To be honest, I’d forgotten that I’d made the suggestion until I saw Greg’s comment earlier this week.

It just goes to show that you never know where an idea might lead.  I made a simple suggestion about an idea I’d seen about a forum discussion.  Tomorrow, it’s going to become reality.

For whatever reason, it made me think about the following meme.

Image result for sharknado meme

So the moral of the story: if you have an idea, don’t keep it to yourself.  You never know where it might lead.

#BI101: The need for having both a DW and cubes

This is part of a series of articles in which I’m trying to teach myself about BI.  Any related articles I write are preceded with “#BI101” in the title.

This morning, this post from my friend and fellow SQL Saturday speaker, James Serra, crossed my inbox.  (Hope you don’t mind me sharing, James!)  Because it fits very nicely into my personal BI education endeavor, I wanted to post a link to his article, both for my own reference and for anyone else looking for more information.  His article includes links to other articles about BI.

James and I are both speaking at SQL Saturday #741 in Albany a week from tomorrow (July 28).  Come check out our presentations, and feel free to use the opportunity to ask us questions and to network!  Hope to see you there!

SQL Saturday #741, Albany, NY — Come to upstate New York!

On Saturday, July 28 (a week from tomorrow as I write this), our local Albany-area SQL user group will host our fifth SQL Saturday!  I have participated in all five; I worked as a volunteer at the first one, and I presented at the other four (including next Saturday).  This is one of my favorite events, and I look forward to it every single year!

This year, I am debuting a brand-new presentation: “Networking: it isn’t just for breakfast anymore,” based upon my ‘blog article of the same name.  (An alternate name for it could be “Networking 101: networking for beginners.”)  This presentation is primarily for people who want to get better at networking but don’t know how to do it, although seasoned veterans might be able to get something out of it as well.  It’s one of the first sessions of the day (8:30 am!), so come early!

As much as I promote my own presentations, mine is not the only one on the docket.  There are many wonderful speakers and presentations being given at this event, and I encourage you to come out and check out as many as you can that interest you!

SQL Saturday is always a great time, a great opportunity for free learning, and a great opportunity to network with data professionals.  The Capital District region here in upstate New York has been my home for many years.  I hope to see you here in my home turf!

The document development life cycle

A recent work request reminded me of production life cycles.  I got an email regarding a user guide for an application that I had written earlier this year.  She said she was looking for something similar.  She asked me how long it would take.  I told her that I would need to look at the application, but I also said there were a number of things to consider, including how much access I could have to the application so I could test and document it, who would be available to answer any questions I had, who would be able to test and review the document, the document format, and so on.  (On hindsight, I also realized that I’d forgotten to ask a very important question: who is the audience?)

The conversation reminded me about the importance of the document development life cycle.  In an earlier article, I talked about a number of issues that frustrate people who understand technical communication and documentation.  This is another frustration that is poorly understood and widely ignored.

I’ve had the privilege of having worked in both software development and professional document development environments.  Many people fail to understand that there is no difference in the production process between the two environments.  To put it another way, the development life cycle between the two is no different!!!  The software development life cycle (SDLC) is widely known and an industry-standard term.  But if you’re not a technical writer or communicator, when was the last time you heard any mention of a document development life cycle?  For that matter, are you even aware that such a thing exists?

It seems to me that most people aren’t.  How many of you have been frustrated when you’re given a documentation project, whether it’s an application, a process, or a product, and been told that it needs to be finished in a couple of days (or even a couple of hours)?  This is completely disrespectful to technical writers, and it upsets me to no end.

An example of a software development life cycle
(source: SoftwareTestingMaterial.com)

Like software, producing good documentation follows a life cycle.  Here’s a sampling of what takes place when developing a document.  Document requirements must be defined: what is being documented, what is the scope, and so on.  And let’s also not forget what may very well be the most important requirement: who is the target audience?  The document must be designed and written.  This involves organization, layout, and design.  Writing it is no small task; I’ve written before about how hard it is to interpret ideas that come from a subject matter expert (SME).  Once a document draft is written, it needs to be reviewed (“tested”) by an SME for accuracy; are the ideas conveyed in the document correct?  Adjustments to the document will likely need to be made, and it will need to go back to the technical writer for editing and updates.  Document format needs to be considered; will it be deployed as a PDF document, or will it be stored and maintained in an online format, such as a Wiki, Sharepoint, or Confluence?  Speaking of maintenance, bear in mind that if the application or process is changed, the document will likely need to be changed as well.

Documentation is a critical, yet overlooked and disrespected, profession in technology.  A technical writer cannot be expected to produce a quality document in mere hours.  As with all quality products, documentation also follows a life cycle.  Whenever the document life cycle is properly followed, the result is a quality document, which, in turn, results in satisfied customers and a positive reputation for your organization.

Want to get ahead? Don’t get comfortable

“Moving me down the highway, rolling me down the highway, moving ahead so life won’t pass me by…”
— Jim Croce, “I Got A Name”

“It’s important to be able to make mistakes.  If you don’t make mistakes, it means you’re not trying.”
— Wynton Marsalis

“Don’t look back.  Something might be gaining on you.”
— Satchel Paige

“Insanity is doing the same thing over and over again and expecting different results.”
— unknown

Late last Friday afternoon, our manager stopped by our workspace for a chat.  Some of it was just small talk, but he also wanted to give us a reminder of something, which is what I want to write about here.  I don’t remember his exact words, but the gist of what he said went something like this.

“We want you to develop personally and professionally,” he said (or something to that effect).  “The way you do that is to take on tasks that you know nothing about.  Volunteer to do things you wouldn’t typically volunteer.  If you see a support ticket, don’t worry about looking to see whether or not you know what it is or if you know how to handle it.  Just take the responsibility.  That’s how you develop.  If you want to move ahead, you need to step out of your comfort zone.”

Indeed, these are words to live by, and it isn’t the first time I’ve heard this.  I have had countless experiences where I’ve been told that I need to step out of my comfort zone in order to improve.  In my music experiences, especially in my ensemble performance experience, I’ve often been told by good music directors that I need to attempt playing challenging passages to get better.  When I first started doing CrossFit, one question we were asked was, “would you rather be comfortable or uncomfortable?”  The point was that in order to get better, some discomfort would be involved.  I also remember one of the points of emphasis back when I took a Dale Carnegie course; each week would involve stepping a little more out of our comfort zone.  We would do this gradually each week until we reached a point where we had drastically improved from where we had started.

Falling into a rut is common, and while it happens in all different facets of life, it is especially easy to do in the workplace.  Sometimes, the work environment can slow down, and you have a tendency to fall into a routine.  I’ve had this happen more often than I want to admit, and more often than not, I’m not even aware that I’m doing it.  Every once in a while, a pep talk or some kind of a jolt (such as a kick in the butt — whether it’s from someone else or myself) reminds me that I need to branch out and try new things if I want to get (and stay) ahead.  I am well-aware that I need to step out of my comfort zone to get ahead, but I am also the first to admit that I will sometimes forget about this, myself.

Too often, I see people who fall into ruts themselves, and who have no desire to step out of their comfort zones.  As much as I try to tell these people to at least try to do something about it, they insist on remaining where they are.  These people strive for mediocrity, which is a major pet peeve of mine, and something for which I have no tolerance or respect.  People want to remain in their “happy place,” but what I don’t understand is how these same expect to get ahead, yet refuse to leave their comfort zones to do it.  These people will be stuck in a rut forever, and they have no right to complain about it.

Everyone has a dream, or at least some kind of goal they want to achieve.  The fact is, if you want to reach that goal, or at least take steps toward it (whether you reach it or not), you need to get uncomfortable to do it.

Instant decisions


(Source: New York Times)

A NY Times recap of a ballgame got me thinking about instant decisions.

I watched this game on a TV at a restaurant where I was having dinner with my wife.  I remember watching Brett Gardner getting thrown out as he was caught in a rundown between third and home.  I remember thinking, “now the man on third is erased.  What were you thinking, Brett?”

As the Times article points out, it ended up being a fateful decision by (Orioles pitcher) Dylan Bundy.  Had he thrown the ball to the shortstop instead of his catcher, he potentially could have turned a double play to get his team out of the inning.  Instead, the Yankees, with an extra life, rallied in the inning to go up by a score of 5-0 (highlighted by a Tyler Wade grand slam).  The Yankees ended up winning, 9-0 (making me, a Yankee fan, happy).

But this article isn’t about the game.  It’s about the instant decision.  In this case, a quick decision ended up affecting the outcome of a ballgame.

Think about all the times in your life when you’ve had to make an instant decision on your feet.  We’ve all had them.  How did they turn out?  Good?  Bad?  Did they end up changing the course of your life, or were they just blips on your lifetime radar screen?

I’m sure there’s some kind of psychology as to how your background — upbringing, education, etc. — might play a role regarding the kinds of split-second decisions you make, but this is a subject about which I know nothing.  Rather, it got me thinking about the idea that quick decisions can have consequences.  In the scheme of things, many of them might not have any effect.  But depending on the time, place, and circumstances, such decision-making could have disastrous consequences — or result in the opportunity of a lifetime.