I loved the flash-in-the-pan band Semisonic, best known for – okay, only known for – their hit song Closing Time. I thought the rest of their stuff was just as brilliant (She’s Got My Number is one of my favorite songs ever), but I was in the minority, because they disappeared off the rock radar pretty quickly.

The band’s drummer, Jacob Slichter, wrote a book about the rock star experience called So You Wanna Be A Rock & Roll Star explaining what it was like to rise and fall in popularity. I bought it just to get a glimpse inside the crazy rock star lifestyle written by somebody who hadn’t been strung out on drugs. Great book.

This week on a plane to San Francisco, I found myself staring at a copy of Quest Software’s ad in the latest SQL Server Magazine, and the part that grabbed my attention was the bottom:

The tagline of Quest’s SQL Server marketing group is, “Be a SQL Server Rock Star with Quest.” Then it hits me: I should probably write a blog entry about what I do for a living. I’m no Jacob Slichter, but I have one hell of a fun job.  I’ve gotten a couple of questions about what the job title “SQL Server Expert” really means, and how you get a job like this. Today I’ll focus on the job, and tomorrow I’ll talk about how you can get a job like this.  (No, really.)

I’m an in-house resource for people at Quest who need to know something about SQL Server. Now, keep in mind that Quest has over 3,000 employees, hundreds of which make their living working with SQL Server. I work with people who write code to work with SQL Server, people who write documentation on SQL Server products, people who test SQL Server in ways I never knew existed, and people who support huge companies using SQL Server. Most of the time, when these people ask me a question, I look at them and think, “Holy cow, your question is so smart I can barely comprehend it, let alone answer it!” Quest hires smart people, and they ask hellaciously tough questions. Sample of one in my in-box right now: “Can logical fragmentation of a heap ever hit exactly 100%?” Whoa. I understand the question, and I think I’ve got a handle on the answer, but I don’t know for sure and I’m going to have to do some cool experimentation just to find out.

Sometimes they’re easy, but sometimes they’re hard-core technical questions that require serious research and testing. At times like that, I have to go find the answer out, and that usually means some pretty cool research. I maintain a big virtual server lab with my own Active Directory domain, mail server, file servers, and a dozen SQL Servers with various test databases in wacko configurations. That helps me find out strange answers fast.

My job revolves around getting these questions answered. At any given time, my to-do list includes questions like:

• How can Quest build tools to make SQL Server management easier?  (Sounds easy, right? Try answering that to a roomful of very smart people who are about to bet money on it.)
• What features do we need to add to LiteSpeed to help SQL Server 2008 users?
• If a customer is having performance issues writing backups to a particular make/model of SAN, where should they look?
• What podcasts do we need to record in the coming months that DBAs would want to watch?
• What do DBAs think of the way a particular feature works?

I work with my internal customers and my managers to prioritize the flood of questions and then solve ’em. As soon as a question comes in, I need to figure out:

• Am I the right person to find the answer? Quest has hundreds of SQL-savvy people, and there might be somebody who already knows the answer to this question.
• How long will it take me to find the answer? I need to quickly give the requester a ballpark idea of when I’ll be able to give them an answer – even if I don’t yet know how I’m going to get that answer. Is it a one-hour question, or a one-week question?
• What’s the priority of this question? I’ll never be able to fulfill every request that comes in before my day is over, so I have to balance what’s coming in with what I’ve already got on my plate. This is harder than you might think at a new company – I get requests from people I’ve never heard of!
• How will I get the answer? What’s the actual work that I need to do in order to figure out the problem? Do I need to test it on different SQL Server platforms, with small or large environments, bounce it off my Twitter peeps, ask Microsoft, build a new server, etc. A lot of my questions involve building a little project plan to make sure I don’t leave something out. I don’t wnat to tell a programmer, “This is how you solve that problem,” only to have my answer get deployed in a commercial product – and have it not work right.
• How do I communicate the answer? Since I’m in the answer business, I need to find out how many other people might want that answer, and figure out how to get that answer to them. For example, if it’s a technical question about how a particular feature works in SQL Server, I’ll write up the answer in a blog post or a SQLServerPedia.com wiki article, or maybe record a podcast about it.

This communication need is one of the reasons I’m really excited about the new SQLServerPedia wiki. If you’ve been reading my blog a while, some of my posts are really, really long – frankly, too long for blog posts – because I’m covering a technical issue in-depth. My SQL Server tuning with Perfmon article comes to mind. Instead, it makes sense to shove that into the wiki as an article and let other people edit it and enhance it.

Anyway, that’s my job. In the process of answering questions, I get to learn a lot of cool stuff, meet a lot of cool people, and see a lot of cool places. As I write this, I’m on a flight to San Francisco to meet with our SQL Server marketing guys for a couple of days.

So how can you, dear reader, get a job like this? Stay tuned for the next episode.