So I thought about this one a little more, and I think I'll make it into an unintentional two-part T-SQL Tuesday post. In my initial post, I expressed my gratitude to AirborneGeek (t/w) for bringing me into the madness that is databases. But I didn't really tackle the intent of his topic for the month.
Kerry, you know where I came from. You know my aviation background. So you know that I 100% believe in the importance of being able to learn from other people's mistakes. It's a big part of how pilots learn not to break things.
I didn't set out to be a database person. I didn't intend to be in this place. But I can't exactly say that I didn't ask for it. I'm apparently more masochistic than I thought. I mean, when I met you, I was a ColdFusion developer...... Now I'm a DBA. I could have had a much lower-stress life if I'd just stuck with being a pilot. Sometimes I question my life choices. But it is what it is, right?
I submitted late this month, and I wish I hadn't procrastinated. I think your topic was excellent, and it is something that I completely understand. The global airline industry had to suffer some very hard lessons before they realized that knowledge-sharing, especially of the bad stuff, was actually an extremely good thing.
I spent years as a Flight Instructor. You don't learn from perfection. There have to be mistakes. That's what "learning" is. But, sometimes, it's better for you if someone else had to learn the hard lessons first. Just so long as they tell you about them. And if you listen to what they did wrong, maybe you won't go down the same path.
I could probably write pages about how to assess a risk and how to manage that risk after you've assessed it, but it always starts at the same place: you have to be able to IDENTIFY that risk first. And no matter what the topic is, you don't know what you don't know. Murphy understood that. And I'm willing to bet that anyone who has worked with any sort of system for longer than a few months understands that sometimes things break unexpectedly. Most businesses that I've ever been associated with work at a pace that's much more appreciative of your ability to quickly find the solution on Stack Overflow. I'm willing to gamble that most people would prefer not to be the first person to write a blog post about what they found out and how they fixed it.
Honestly, off the top of my head, I can't think of any unique problem that I've run into that I haven't been able to Google my way out of. I'm also fortunate to have an exceptionally good team that is able to cover the subject areas that I'm not an expert in (like the network). I got a rather late start in the DBA game, so I don't have Bertrandian levels of experience as the Guardian of the Databases. But when I was primarily a programmer, I was grateful that I wasn't that person when a database went sideways, and I've also come to appreciate that I used to be an extreme database abuser. I never really would have had the opportunity to ask Kerry silly questions if I hadn't been.
In answer of this month's T-SQL Tuesday, I don't really have my own individual story to share, but I can affirm the importance of both sharing information that you probably wouldn't want other people to know and of accepting that information without any sort of judgement. There's a reason that people warn about making sure that you have a WHERE clause when you DELETE something, or the joys of accidental Cartesian JOINs on large tables. At some point in a career, everyone has done it. Or they will.
It's really hard to top a willingness to talk about what went wrong when your error cost millions of dollars and possibly hundreds of lives. But, if an airline can talk about how they screwed up, then no company should have even a tiny problem recapping the decisions they made that caused a multi-terabyte database to go poof at 4PM on a Friday.
And no DBA should be too remiss to learn from (and not repeat) those mistakes.
No comments:
Post a Comment