SQLServerCentral Editorial

Knowing What You Don’t Know

,

Today we have a guest editorial from Grant Fritchey as Steve is traveling.

I’ve been reading a fascinating history about Audrey Hepburn and her experiences growing up under occupation during World War II. Not only is her personal story riveting, but the details around the occupation are also frequently new knowledge for me. I’m a huge history nerd. I read quite a bit of history, and it just fascinates me. However, reading this book, I realized that I have enormous holes in my knowledge, forcing me to reexamine what I think I know.

I believe it’s vital that we, as data professionals, continuously reexamine what we think we know as well. I recently wrote a blog post on this same topic, lamenting that people weren’t learning Extended Events because the early launch was, frankly, bad. Yet, things have radically improved, but lots of people, including ones I respect and admire, haven’t gone back to reexamine the issue. They didn’t know that things had changed. They had gaps in their knowledge.

So, my question today is, how do you go about identifying that you have gaps in your knowledge?

Let’s paraphrase Donald Rumsfeld a bit. There are the things that you know you know. There are the things that you know that you do not know. Having this boundary is vital. Being honest about it is even more so. However, there are also things that you do not know that you do not know. How do you go about tracking those down? Should you bother?

I have a recent example from a question online. A group was taking server backups. The whole server. They weren’t backing up databases. Well, a database became corrupted. They went to their backup, but couldn’t restore the entire thing. That would mean taking down the server. They managed to pluck an MDB file out. However, that wouldn’t restore, no matter what they did. Then they started trying to attach it, which also wasn’t working. In short, they didn’t know what they didn’t know about backups, restores, attachments, corruption, and disaster recovery. That lack of knowledge about their lack of knowledge hurt them.

Short of sprinting straight into a brick wall, learning the hard way, how do we go about narrowing that gap? How do you go about narrowing that gap? Do you bother trying to narrow the gap?

Rate

5 (1)

You rated this post out of 5. Change rating

Share

Share

Rate

5 (1)

You rated this post out of 5. Change rating