I wrote this over 10 years ago, and it still holds up.
Some time ago a colleague asked “If you could give a DBA just one piece of advice, what would it be?”
“If you could give a DBA just one piece of advice, what would it be?”
There are a great many thing I tell aspiring DBAs, whether or not I’ve actually been asked.
Study.
Know what you know.
Remember to keep rebalancing work and life.
Talk to other DBAs. Talk to your devs. Talk to your users.
Stop using cursors, darnit.
A little less cream in the coffee next time.
From my many years in the field, many interviews conducted, many tragedies experienced and averted, many hours spent in extra-vocational activities, I can absolutely distill everything I want you to know down to one simple thing: Test your knowledge.
Certifications?
When I say test, the audience instantly thinks certification, and runs off to Amazon to buy the self-based training kits. Of course you can test yourself by taking a test, no question about it. In fact, we often advise new DBAs to follow a certification training program – either the kit, or a class, or just the topics outlined in the “Skills Measured” section on the exam’s web page.
But, understand that studying for a test, and even taking the test, is not truly testing your knowledge. You’re learning, and you’re testing your ability to pass the exam. Good pursuits, yes, but this is not what I’m talking about.
Interviews?
A good interviewer will absolutely test what you know by asking you a bunch of questions, and staring at you severely as you answer. But again, this isn’t really what I’m talking about. You prepare for interviews, good. You get interviewed, also good. But this also falls under learning and passing (or failing) a test.
So, testing your knowledge with interviews and certification exams don’t count. What does?
Hands On, Real World, Live-not-Memorex
Once you learn something, do it. Find out if you really know it. Test your knowledge.
If you can’t do it at work, do it at home. I’m talking about everything you learn, from the ground up.
Heard that the new data type has a range of here to there? Create a variable of that type, and put some data in it.
Found that you have a need to add nonclustered primary keys to tables at work? Practice doing that, in code. Check out the options available for that statement and play with them.
Recursive CTEs have a maximum default recursion level of 100? Make a recursive CTE. See what happens when you go more than 100 levels deep. See if there’s a way to change that default behavior.
Never tried a piecemeal restore before? Do one! Do ten! Read up a little on BOL and try out the different restrictions and rules. Break the thing on your test box. Have a little fun.
Get into types, and new code, and high availability scenarios. Get into anything you’re likely to need in your career – not just at your current job, in your career. You can test most of your fundamentals on a single instance of SQL Server Developer on your personal laptop. Many of the more advanced lessons can be accomplished the same way, or with the help of virtual machines.
If you get a complicated enough thing you want to explore, see if your company will spring for a little room in a test environment. Explain that you’re expanding your skillset on the advice of a Microsoft Certified Master*, to be sure that you’re well prepared for the expanding data needs of the company. Companies LOVE self-study, because it’s cheap, and because you’re demonstrating a dedication to the job. Most will be pretty happy to give you a little space in dev if you show interest. A very few will become paranoid, and fear that you’re trying to grow beyond them. Test yourself on your own time, and at least consider making their fears come true.
And remember that at any step of the way, dozens and hundreds of people who have done this before are out there on the web, waiting to answer your tweet, forum question, or blog.
Blogging and…
Blogs are another excellent way to test your knowledge, in the true “trial by fire” sense. Why on earth is blogging a true knowledge test, and Microsoft exams aren’t? Because you don’t truly know a thing until you’ve explained it. Decades upon decades of students bemoaning essay questions, and rejoicing at multiple choice, bears me out on this.
You don’t know a thing until you’ve explained it. Or, to paraphrase Steven King, until you’ve written something down, how do you know what you think about it?
Explain how something works, or why it’s faster or better or different from another thing in SQL Server. Blogger newbies find very quickly that it is very difficult to explain a concept clearly. You find out even more quickly where the holes in your knowledge are, and that’s the key.
What’s the difference between char and varchar? Well, varchar is variable length, and char is fixed. Great, now tell me how that’s instantiated. If you can’t explain the simple facts on the ground in a handful of words, you need to clarify your own thinking. Run an example or two for yourself, clarify it, and then write it down. This is how you build solid knowledge. What’s more, it’s how you save solid knowledge – any blogger worth his or her salt will have, at some point, looked up a bit of information in their own blog.
Many people take the next step and become community and conference speakers. This is certainly an option, but not a requirement.
Test Your Knowledge
I run up against gaps in my own knowledge all the time. I do my best to make sure that happens when I’m playing around on my own computer, or at worst on the development environment. I don’t want to run into one of those black holes of ignorance when I’m working on a corrupt database with the VP of All the Things breathing down my neck, or when I’m talking with a client about their DR strategy, and most certainly not when I’m interviewing.
As much as you can, test your knowledge. Get your hands on the product. Explain what you’ve done, if only to yourself. That makes the exams, the interviews, and the job a piece of cake**.
Footnotes:
*Go ahead, name drop…they won’t recognize the name, but they’ll get that they SHOULD be impressed anyway.
** Well, comparatively.