I recently went to our local pharmacy to pick up some prescriptions. There was one for my boy and one for me; at the time I didn’t think much of it to check. I had seen the last name on the slip for both and moved onward with the business of the day. What I didn’t realize is that I had picked up a totally different prescription for a gentleman with the same last name as me for something that had nothing to do with me.

A number of emotions ran through my mind some not so good, but some actually made me think of my day to day routine and work as a SQL Data Professional:

What was the root cause of how the issue occurred?

Was it a manual process or automated?

What processes are in place for this to not happen?

Security in general (information was on the slip for the other gentleman)?

What could have been the outcome based on taking the prescription?

Sure, I’m human, and you bet I was frustrated by the situation. The questions above come into play every day if we look around. Think about it for a minute if you will. How many times are we going about the business of the day and truly aren’t paying attention? Or maybe we are working on an issue at work or in a shop and giving an issue a “what for” only to come to find out we weren’t correctly diagnosing the root cause of the issue, to begin with.

What is the root cause of how the issue occurred?

This seems like a logical question we would ask when dealing with a scenario. I’m guilty at times for triaging quickly and moving on; it is only when I step back and look at the true issue at hand will it then become extinct and truly eradicated. A wise boss I have once told me to always look for and identify the root cause; sure you will have to remedy the problem, but to truly fix the problem you need to address it at times further upstream. There will be times where you are not the one to fix the root cause and guess what? That’s okay. Yep – it is okay but you do your due diligence and bring that to the attention of others who may be able to fix that root issue.

Was it a manual process or automated?

For anyone who knows me knows that I love automation. Some may look at this as it pushing me out of a job. Quite the opposite for me; it has helped me to become more efficient and streamline many mundane daily activities. When I first became active in the SQL community six years ago I came upon a post by John Sansom (B|T) that dealt with automation. The concept has stuck with me and I am glad it did. Look around you in your daily routine; what can you automate? What should you automate? What processes can you enhance that will allow you to become more innovative in other areas?

What processes are in place for this not happen?

If you, dear reader, don’t get anything out of this post then I hope you tune into this section. If you identify a problem address it or get it addressed; too many times I’ve seen issues just get swept under the rug only to have the same problem happen again for the next data professional to fix. As I type this I’m even taking inventory of my own practices. Always have the mindset of making your practices better; don’t become stagnant. If you become stagnant then you are not innovating. Challenge yourself daily to make an impact – you be the game changer.

Security in general?

How many times have you seen security become an afterthought? I’ve seen it my whole career; it can quickly become the end of a project. Or better yet, if you work with a lot of installs and vendors, you will have the fun ability to just make everything SA. That should do the trick; just let me hop on your network and do whatever I want to do for the install. As a data professional and more specifically since I am a DBA, it is your duty to protect the information you are responsible for. Security is something that you should take seriously from day one. Do not make this an afterthought; if you do then the repercussions could be detrimental to any business.

What could have been the outcome based on taking the prescription?

As you work through any issues think about the outcome of what you are doing and the impact you will make. If you are changing architecture or schema how will that affect something else down the line? Maybe you just throw in an index not knowing if it will work better or affect something else down the line. Backups????? Eh, who needs them. Let’s just shut those things off. Oh yeah, I have backups but I’ve never restored one (don’t let this be you).

These are all scenarios I’ve seen over and over again. Think about working into your daily routine and thought mentality to think about the outcome of what is being done and the impact it will have on other business functions.

Conclusion

As we move through our daily routines and become frustrated at times with issues think about these 5 questions. They are simple in essence; don’t overcomplicate things. Look for the root cause and think about how to address it properly so it does not continue to happen. Don’t sweep issues under the rug. I still remember the saying from when I was growing up ingrained in me and I’m sure some of you have heard it as well ~ “Don’t put things off until tomorrow what you can get done today.”