It’s been a while since my last post, there are various reasons for my absence: work, illness, having our house rewired, etc., but one of the biggest reasons is my struggle with how a few folks in the SQL community treat the PASS organization and those that volunteer their time to PASS.
As many of you know, I do a lot of volunteer work for PASS. I do this because it’s an organization that I truly believe in. It was created by the community for the community. It’s a place where data professionals can exchange knowledge freely, no strings attached. To my knowledge there is no other community in the IT world quite like it, we even have our own hashtag on twitter, #sqlfamily. But lately I’ve been struggling with how a few community members have reacted to policies/procedures/contracts. Essentially starting a fire, pouring gas on it and walking away.
I’ve been involved with the Program Committee (they are the folks that select the content for the annual Summit) since 2010. I took over my local PASS chapter when the existing chapter leader stepped down. I help out with local/regional SQL Saturdays when my schedule allows. I moderate 24 Hours of PASS when my schedule allows. I volunteer while on site during the Summit as an Ambassador. I’ve served on the NomCom (2012). You get the idea, I am a true believer and not just in lip service, so when someone “attacks” an organization that I truly believe in, I get more than a little irritated.
One thing I have learned throughout the years of being a DBA is that you need to be able to prove a problem is NOT yours by exploring all the other possible areas that could possibly be causing the problem. You have to look at it from all angles, not just the DBA angle.
We’ve all been there. Customer calls to say application is slow and a trouble ticket is automatically created and assigned to the DBA team because the application uses a database. This is somewhat akin to saying the issue with a car’s performance is the gas – all cars use gas so it must be the gas. It’s tiresome and frustrating, but we go through motions to prove the issue is not ours. In the financial world, it’s called due diligence.
This kind of due diligence has proven to be useful in other areas of my life, both personal and professional. I would ask that those in the community please do their own due diligence BEFORE posting a blog, sending a tweet or starting the good old fashioned room mill. Lately several community members seem to have forgotten the kind of influence they carry with the rest of the community and not done their due diligence before posting a blog, sending a tweet or starting the rumor mill.
You will notice that I did not name any names. That would really defeat the purpose of this post. I don’t want to start a fire with this post then allow gasoline to be poured on it with all the comments (not that there would be tons, because I don’t carry a lot of influence in our community – not a slight, just stating a fact) and then walk away.
I want you ALL to think about what you post, tweet or say BEFORE you do it.
SQLSwimmer 
First, thanks for your efforts with the committee. I know it’s hard, and will always open you to criticism. I agree that someone should be careful about what they’re writing, but I’d also ask that you, and the committee give us more detail and more information that explains why decisions are made.
I’m not sure you need to defend things, but provide some reasonable explanations on your choices. Releasing rankings in aggregate or other totals would go a long way to allowing others to see the world through your eyes.
“One thing I have learned throughout the years of being a DBA is that you need to be able to prove a problem is NOT yours by exploring all the other possible areas…”
I’d beg a different opinion or approach. I prove it is not a DBA problem simply by providing one or two statistics, such as sql statement level statistics (i.e. duration, reads/writes, # of executions) at the troubling time vs the same statistics at different non-troubling time.
Jeffrey – While your opinion or approach is perfectly valid and is what I usually start with, in my experience, it isn’t always enough. While you and I as DBAs know that it should be, non-DBA IT and/or management folks often times require more.