There are some questions that can’t necessarily be answered in a book or a training video.  Those are often the questions revolving around “why?” rather than “how?”.  A prime example from my own experience is my lack of understanding of the criticality of transaction isolation levels.  As a very green SQL Server professional (and in this case, I define professional as the one who knew where to find the SQL Server 2000 disks), I had learned enough about transactions and the different isolation levels that I understood, at a high level, what these terms meant.  However, at the time I worked in a small IT shop where there was only one SQL Server installation, and the number of users on that database system was quite small.  Through the myopia of inexperience, I couldn’t understand why there was so much focus on dirty reads, phantom reads, concurrency, or even transactional rollbacks.  Envisioning only my current environment, it was difficult to conceptualize that more than one of my 20 or so users could be accessing the same record(s) at the same time.  So while I understood the basics of “how”, the “why” was elusive to me.

Talking with others who work in IT, I’m constantly reminded that there is a community around SQL Server that seems to be unmatched in any other sector.  I see everyday where SQL Server professionals go out of their way to help out others with no expectation of repayment.  Still, as altruistic as this community often is, I think there’s still a barrier for some of those who are new to a role in supporting SQL Server.  Those of us who have been around for a while tend to speak in language that is highly specific to our profession, and we sometimes assume that all of our fellow professionals possess a certain baseline of knowledge regardless of their experience (or lack thereof).  This can have the unintended effect of creating a barrier for the less experienced, who have a desire to learn but don’t want to appear completely clueless in front of more experienced colleagues, and as a result there are a lot of questions that go unasked.

Again, these are often questions of a nontechnical nature – after all, an inquisitive newbie can do a quick web search and find a blog, article, or even a video to describe how to accomplish a specific technical task.  The more difficult – and fundamental – inquiries are those that ask, “Why is this important?”  I think we need to have more open opportunities to have these types of questions asked and answered.

To spur on the conversation, I’m going to post a series of blogs that will chronicle some concepts I was afraid to admit that I didn’t quite get, along with the truths I’ve learned since.  Starting next week, you’ll see blogs tagged as “Afraid to Ask”, and I encourage those of you who are new to a role in SQL Server (or perhaps you’re new to a particular discipline within the product) to inject your own quandaries either as comments on this post or in a private message to me.  I’ll do my best to address all of the feedback in future blog posts in this series.