I love music, so I listen to a pretty large variety of it, but I will admit, most of it comes from a pretty narrow set of artists/time range. Part of this is because my favorite artists are also sort of philosophers. From time to time, I hear a lyric that piques my mind about computing, and 100% of the time, it is NOT a song about computer problems. No artist is quite so close to a philosopher for me as Pete Townshend.

In his song “Slit Skirts” there is a line that is definitely not about being on call or keeping and testing a system’s backup.

“No one respects the flame like quite like a fool who’s badly burned.”

But it sure does fit.

Why is this though?

I know that personal failure is a great catalyst. In my blog, (sigh) 15 year ago, What counts for a DBA – Failure, my point was that failure is the best teacher. The prime example, video games.

This is where I learned the weirdest thing. If you play a game like Mario Brothers, something wild happens. You fail a lot. I mean, it might take 100 tries on a level, each try being a horrible failure. But you get just a wee bit better over those 100 tries. You finally solve this level and move on. One and only one successful try. You complete the game, and put it away for a while, maybe years.

When you return, for some reason you can still play a lot of the game just like when you played it years before. And for every programmer out there, you know that you write code the same way sometimes. You write some code, try to compile it, it fails. Once it compiles, you move on to the second most important test, it feels like it works, then you start testing, and find more bugs and continue on in a loop until everything is hunky dory.

But you don’t want to be that fool that is badly burned

If you have truly done the previous process to the proper level, whether you are a coder, administrator, or anyone along the line in the creation of software (or anything really), you can at least know that you have done your best.

It doesn’t prevent you from being badly burned, but at least you can feel good to not have that “fool” label applied.

That terrifying moment when you hit the final testing phase

After you put that well-tested (as far as you know) code into production, you start the real test. Users (doing their work), hackers (doing their best to disrupt that work), and AI (trying to do one or the other.). This is what I like to call the testing in production phase.

Any failure at this point could be very serious. Getting burned by leaking data to the public means that one of those letters we all get each week about our private data being leaked was at least partially your fault (a few more hit my mailbox just this week).

It might even be directly your fault

For example, if you are the DBA that automated the backup process of your sales system, and it hasn’t been working, then the loss of data is your fault when the hard disk system started to fail and write bad data.

There are loads of material to remind us how to test your backups, secure your data systems, monitor automations, etc. If it is your responsibility to protect a system and its data and that protection fails, it may or may not be your fault, whether or not you get the actual blame.

But once you have been burned, either by your mistake or an outside force you couldn’t have imagined, your administration paranoia will increase a hundred-fold. No one wants to be burned in the same place, in the same way more than once.

True for relationships, true for system administration tasks.

It’s okay, everyone gets burned sometimes

Your fault, their fault, stupid or unexpected, as long as no one gets actually hurt due to some form of negligence that could have been reasonably avoided, the final question is “Did you learn something…like not getting in that situation again?”

Just understand that as you get (or claim) more experience, the definition of “reasonably avoided” gets narrower and narrower very single year.