SQLServerCentral Editorial

Even When You Know What You're Doing, You Can Screw Up

,

There I was, walking around Amsterdam, radio in hand (OMG! He's talking about radios again!), automatically transmitting Active Packet Report System (APRS) signals every 90 seconds. Same radio I had used in Chicago a couple of weeks ago and in Poland last week. I was on the correct frequency and, as I say, I had just used the radio to send APRS signals in Poland. For those who don't know, APRS can be used to send direct messages, report the weather, several other things. Mostly though, it's used to track locations based on Global Positioning System (GPS) data. I've got a presentation I'll be giving soon on how I'm collecting APRS data into a PostgreSQL database running on AWS Aurora. As part of the presentation, I'm capturing packets from my travels, just so I have interesting stuff to show during the session. So, anyway, Amsterdam. Here's a picture of the location my radio transmitted in Amsterdam:

Now, the really clever amongst you may have noticed that those street and highway names are not Dutch. And no, my laptop hasn't been converted to Chinese by hacking. No, in fact, my radio was misconfigured. Instead of tracking my location through GPS like it did in Poland and Chicago, heck, everywhere else, it was using a fixed location. Since I never use the fixed location, it's still set to the factory setting. Guess where the factory is? China. I don't think that's the factory location though. That's Xi'an in the Shaanxi province of China, a tourist destination evidently. Someone in the factory probably tested the radios using their favorite vacation spot or something.

So what happened? Well, the day before I had reprogrammed some frequencies on the radio. I didn't mess with the settings on my GPS or my APRS setup. But somehow, stuff got changed. I didn't think to check the setup before I used it. I just assumed everything was fine.

I can't begin to tell you the number of times stuff like this has happened to me in IT as well. I love to share how I've never dropped a production database. Nope. Not once. Not ever. Yet. I mean, I've dropped a few things in production: tables, columns, data, logins, views, procedures, functions, agent jobs. However, never a production database. Is it because I'm incompetent?

No (at least, that's my story and I'm sticking to it).

It's because we live in an imperfect world. Stuff can just go wonky on us at the worst of times. It's shockingly easy to make mistakes. A seemingly unrelated command or button press can unleash all sorts of unexpected hell. I know you know what you're doing. However, I also know, some of you have dropped stuff in production as well. My purpose here isn't to call you out on this. Instead, I want to focus us in a slightly different direction.

We know stuff can go wrong, despite our knowledge, despite our preparations, despite our automation. Yep, despite the fact that we absolutely know our jobs, stuff sill goes wrong. The key here is to assume that. Assume, despite your real skill and obvious knowledge, there may gaps in that knowledge, you might fat finger a command, or something just jumps up and bites you. Assume this. Then, work on your versatility. Get to where you can work your way around it. Learn from the mistakes and the little hiccups that come your way. Build your systems and your processes with the full knowledge that skilled though you may be, you can still cause problems.

I fired up my radio for the walk to work this morning in Amsterdam:

Fixed it!

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating