Jeff Moden, the newly named Exceptional DBA of 2011, is hardly a mystery, but he’s a man of many identities.
He calls himself an “Accidental DBA.” His title at DiscoverReady is Lead Application DBA and Data Architect. He’s known as a writer for SQLServerCentral.com whose articles are often read by tens of thousands. He is the lead advocate for the Anti-RBAR (Row by Agonizing Row) Alliance. He’s also a pool player, beer drinker, magnet-buff, quilter, gardener, motorcyclist, and partner to his life-long love, Debbie. But perhaps most of all, he’s a natural-born helper of others.
Jeff somehow cleared enough time to talk to Bob Cramblitt about the life of an exceptional DBA. An edited version of the Q&A follows.
How did your nomination for Exceptional DBA of 2011 come about?
Several people suggested that I apply and I thought “What the heck… why not? It won’t hurt.” But I didn’t want to nominate myself. I sent some of my peers at work and my PASS chapter president an email with the URL for nominations and asked, if they thought me worthy, would they please say a few kind words on my behalf?
It turns out that all of those I asked submitted a nomination and their words were kind, indeed. I’ve not seen all the write-ups but I was really and truly taken back with the fervor of the ones I did see. I knew that I’d made some impact on these good folks’ professional lives but I never expected the extremely kind and nearly evangelical words that they wrote.
How did you become a DBA?
As with so many others, I’m an “accidental DBA” – the world of SQL Server was thrust upon me by events.
Many years ago, my boss was planning for some huge growth within the next year and was worried about scalability and the amount of work I might have to do to keep up. He had hired a consultant, Rich Bay, for a different task and Rich told him of Microsoft SQL Server, Version 6.5 at the time. Rich set up our first server – which had a single P4-350 and a small 1.5 GB RAID-5 array – showed me a couple of basic principles on the server and domain controllers, and took me shopping for a couple of books on SQL Server administration and implementation.
My life hasn’t been the same since, and that’s a good thing because I love what I do.
In your finalist statement, you quote someone who says “The Exceptional DBA is the person you go to when you need help.” Why did you decide to become a person who helps?
I come from a long line of teachers and so I’m not sure I actually had a choice in the matter. It seems to be something engrained. 😉
My first opportunity to really “pass it forward” came in the Navy where I qualified to teach all 26 weeks of the “Basic Electricity and Electronics” course at Fleet ASW School in San Diego, Calif. I also had the extremely rare opportunity to develop and co-author a five-week course on “Computer Assisted Diagnostics,” which used some (at the time) new technology called “microprocessors.”
In my first professional job in civilian life, I taught myself about spreadsheets, word processing and drawing packages (all new at the time) well enough to begin teaching others in company-sponsored, in-house training courses I was allowed to design, write and teach.
The real opportunity to become a “person who helps” in the world of SQL Server was quite by accident. Al Barash, my boss at the time, sent me to a week-long course on SQL Server implementation. During the fifth day of training, I asked my instructor how to detect and delete the duplicates in the data we were receiving from various third-party vendors. He gave me the same technically correct, yet incredibly useless, answer that I had found on various forums: “If you’ve designed your database correctly, you shouldn’t have dupes.”
I spent the weekend after that trying to work out the problem of eliminating the duplicates without a loop and almost gave in to teaching myself how to (gasp!) loop. Then I remembered a thing called a “self join” (which I hadn’t actually used for anything up until then) and played with it until I came up with the magic I needed to find the duplicates. Once that was done, deleting the duplicates was a breeze.
At that point, I wondered if any of the other folks I’d run across in my search for a solution had solved the problem yet. None had that I could see. I decided that those other folks could use a leg up and I posted my coded solution.
In the process, I noticed other unanswered questions, some of which could be useful knowledge for the future, and I simultaneously realized that I really didn’t know as much as I thought I did. I studied, played with a lot of code, and worked out solutions for some of the questions. Then I posted my answers as thanks for giving me the additional opportunity to learn something new that I hadn’t found in any of my books.
I wasn’t looking for it, but the response was absolutely overwhelming. Some were incredibly thankful. Others joined in with their own solutions which I, of course, learned a great deal from.
That original forum (Belution.com) is long gone, but I was fortunate to find another with the same incredible sense of community: SQLServerCentral.com.
What do you want other DBAs to get from your articles and presentations?
What I really want people to take away from my articles, other than the obvious subject matter, is that one simple experiment with code is worth a thousand expert opinions.
Trust no one with your code. Not even me. Learn how to build gobs of test data to mimic the requirement and then do what I do in almost every article or presentation that I write about code: Correctly define the problem, build the code to solve the problem, and build the test data to test not only the accuracy of the code, but the performance of it and any methods others may suggest.
How do you decide on the subject matter for your SQLServerCentral articles, almost all of which garner 5 stars and are read by tens of thousands?
I don’t pick the subjects; they pick me. I get my ideas for articles from people in need either on the forums or (less often) from problems that occur at work.
The greatest examples of this are the Tally Table article and an article on passing arrays of parameters.
There was a period where it seemed that not a single day passed without someone asking how to pass and use a comma-separated string as part of a “WHERE IN” (a single dimensional array of values). Some also wanted to know how to pass an array of paired parameters such as those you might find in an EAV. I saw a real need and started writing an article about how to pass arrays of data in a pre-SQL Server 2008 world.
Of course, since delimited data was being passed, I needed to use my ol’ friend the Tally Table, to split the data into one-, two- or three-dimensional arrays. As I was writing, one of the metaphorical “dust bunnies” that I’d been kicking around in my head said “Lots of people use the Numbers/Tally table as a black box. They use it but they don’t understand it. How are you going to explain this use?”
That’s when it dawned on me why so many people were having a problem understanding how a Tally Table works – no one that I knew of ever explained how cross-joining to a Tally Table can replace certain loops. So, it was up to me to explain it.
What is your biggest challenge as a DBA and how do you face it?
I face the same problem I believe every DBA faces: schedules!
How do I handle it? It depends on whether it’s a reasonable or impossible schedule to begin with, has unknown requirements or missing requirements that will come later, how critical it is to the overall mission, what else I have on my plate, how much time I’m helping others with tasks they don’t know how to do on other equally (or perhaps more) critical projects, and etc., etc., ad infinitum.
Part of the scheduling problem is estimating. Sometimes we’re given a schedule that just can’t be met for one reason or another and so the estimate comes out as “we’re going to be late because…” I’m afraid I still haven’t mastered the art of estimation because, being a DBA, my time isn’t always my time.
There is one thing that I know for sure, though: If you want it real bad, you’ll normally get it that way... real bad. Keep that in mind the next time you rush a job and the customer calls you six months later screaming about the performance problem that you “built in” or the “non-critical” feature you left out to meet a schedule, or the error checking you left out because you were sure it would never fail. Then, remember that bad news from a customer travels faster than the speed of light to your other customers.
It’s much easier to simply renegotiate deadlines and/or omissions than to take shortcuts without telling the customer.
The bottom line on how to handle schedules? Communication with the customer, whether the customer is external or internal. My philosophy: “Make it work, make it fast, make it pretty… and it ain’t done ‘til it’s pretty.”
What does this award mean to you?
On a scale of 1 to 10…about 1,000!
I never set out to win this award…I just didn’t think there was a chance and no, that’s not false humility. Yet, thanks to the thoughtfulness of an unknown number of people, here I am…going to SQL PASS as the winner of a worldwide contest to choose an exceptional DBA. This is a lifetime achievement come early for me.
But the truth is that this award isn’t about me or any individual. It’s about a concept that, as DBAs and developers, we should all carry forward: share the knowledge we’ve all fought so hard to learn. We’re all in this together. Take the time, every day, to teach someone something new.
Thanks to all of you and thanks for listening, folks.
Editor: Come meet Jeff at the SQLServerCentral party being held during the 2011 PASS Summit.
