I enjoyed math back in school. It’s not one of the reasons that I entered the IT field, but I’m sure it didn’t hurt. I think mathematics satisfied the pleasure center in my brain; it went off whenever I got the problems right. And for a long while, I didn’t even need to understand why it worked. But as I entered advanced mathematics (basically Analysis and Calculus), all of a sudden I wasn’t allowed to be sure if anything worked. I knew it did, but I needed to prove it. I needed to understand the mechanics of how any given equation worked. I needed to prove formulas before accepting and using them in my work.
I find myself facing a similar situation now in my professional development. A week or so ago, I tweeted that I “Nearly picked up Delaney’s 2008 Internals book just now” and while I got a bunch of replies of “That book is great!” and “Kalen is awesome!” I also got more than a few that told me to hold off. And one from Dave Levy (Blog | @Dave_Levy) saying that I should look towards her four-part series on SQL Server 2005 before trying to tackle the 2008 Internals book.
And I think it’s sage advice.
The way I see it, there’s a bunch I don’t know about SQL Server. That’s a sentiment that we all share. A large portion of this missing knowledge pertains to internals and behavior. But on the flip side, there’s a good deal of process and procedures as well. For example, I’ve never had the opportunity to set up mirroring or log shipping. These are things that I need to know to grow my overall skill set. But right at this moment, I probably don’t need to understand why it works.
Don’t get me wrong: I really want to understand how SQL Server functions and behaves. But I’ve got two options. I can either spend my energies adding additional skills to my SQL Server toolbelt, or I can spend my time learning how it works at the system level.
It isn’t to say that it’s all or nothing: learning isn’t black and white. As we gain additional skills, we do learn the basics of how the underlying technology works. As I posted last week, I know that running a large batch of transactions slows down performance because the log holds onto all the transactions until it finishes processing the batch. And I know that by specifying smaller batch sizes, the overall performance will increase as less is held in memory (and written to disk). But try as I might to find a complete, technical explanation for that behavior, I couldn’t. I gleaned bits and pieces of information that I turned into a hypothesis as to why it worked.
Is this mic on?
So what are you thinking? Should I, or any junior DBA, concentrate more on gaining additional skill sets, or do you think understanding internals and behavior is more important up front? Or is a more balanced, learn-about-both approach the best? What did you do when you were learning the bulk of the trade?
Pingback: Tweets that mention Matt Velic » Blog Archive » Knowing versus Understanding -- Topsy.com
August 31, 2010 at 9:07 am
Interesting question Matt. At your level I would think you could split your time between learning internals and adding skills. Perhaps you could start off splitting it 50/50 and make adjustments from there… if you are falling behind on learning new techniques then spend more time on adding skills, etc.
August 31, 2010 at 10:55 am
Noel and Bob – Definitely it goes hand in hand. I know that I learn the most *when* things go boom.
Kendra – I love the details. I can get lost in constantly reading more and more technical articles, but eventually I do have to pull myself out and just get something done. And I’m the same way with books – I’m probably working through two or three of them currently, flipping from one to the next as my attention span and ability to find a daily use in them waxes and wanes.
August 31, 2010 at 9:13 am
I’m with Noel on this one. I see your point that it’s probably better to know how to do something (e.g. log shipping) than knowing exactly how it works, but once something goes wrong, understanding how it works will become just as important.
August 31, 2010 at 9:59 am
This question never goes away. I’ve been working with SQL Server for 10 years now, and I still have the same debate periodically– there are THAT many directions you can go. So this is really interesting to me personally.
Personally, I like to periodically flip through the books on internals/deep theoretical space/whatnot and read them a bit and see if there are topics which are particularly compelling to me or may support something I want to research. Then I’ll read those.
What I *don’t* do is start a thick book on internals and then beat myself up if I don’t finish it. If I move on, I know I can always come back.
Honestly, the way my mind works is that I’m most likely to remember esoteric facts if I’ve used them or if they fit into a particular context of experience somehow. So I just wander back and forth between the experience and the thick books, and stuff sticks into place.
But everyone works a little differently, so I’m sure there’s lots of people who approach this in a more orderly fashion than I do and make it work well.
August 31, 2010 at 2:21 pm
I am running into exactly this challenge myself and have been doing so in every area I have ever worked or taken an in depth class.
Ultimately, I think that it helps a lot to jump back and forth on a specific topic. Figure out how to make a specific thing function, then do some research on why it works that way. Follow that up by applying your research to understand how you could setup the tool better (or even just differently) and research into what the implications of those differences are.
On an even more simplistic level, it makes sense to link learning about the inner workings of something along side a practical application of the knowledge because a lot more of both aspects will be retained.