Keep Calm and Get the Facts

KEEP CALM and GET THE FACTS It often amazes me at how often I find myself apologizing to others for rashly commenting on a problem before I have all the facts. In fact, after so many years as a professional in the IT space and dealing with countless critical situation/severity one problems (a.k.a. Sev1, crit-sit) I would be able to react in a more appropriate and beneficial manner. The sad truth is that, as I write this post. I JUST "did it wrong" on a Sev1 from earlier in the day and found myself sheepishly apologizing for my brash response.

Perhaps by writing this down and publishing for others to read I can obtain the positive results of public shame to result in my correcting my behavior. At least there is a chance someone else can read this and benefit from my mistakes.

The fundamental problem I seem to have is that I hear a few pieces of information or even just the subject line of an e-mail or short text message and immediately jump to a conclusion. Having done a bit of a personal post-mortem, I find that this tends to be my go to response when there is a heightened sense of urgency. Perhaps when there is a Sev1 and my flight or fight response kicks in the adrenaline kicks in and causes my brain to overly react, at least that is the excuse I'm going to tell myself. What can I do about this? First, remember to breath, while it is perhaps a cliche it has been proven over and over again that taking a few deep breaths and making sure you have oxygen flowing helps you to think clearly. I also, personally, think that the time it takes you to breath can help dissipate some of that "nervous" energy that is initially kicked off by the excitement.

Even if you forget to take the deep breaths, the one detail that must not be forgotten is this... Get the Facts. This is summed up quite nicely in a wise proverb which reads "When anyone replies to a matter before he hears the facts, it is foolish and humiliating" (Proverbs 18:13). Let me tell you, I feel like a fool when I realize that I've spoken about a problem, incorrectly. and it all could have been avoided simply by obtaining all the facts, which often are readily available.

Related to this, when you find that facts you have distributed were inaccurate, it is vital to attempt to distribute the correction as quickly as possible. Even if you find that you don't have corrected information, but you know what was previously stated was inaccurate, it's helpful for others to know that so that decisions are not made on faulty details.

I hope that my faults and lessons learned will be of benefit to others going forward.

Comments

Post a Comment

Popular posts from this blog

Using telnet to troubleshoot connectivity.... and watch Star Wars

Image
So the teaser I'll lead off with is, at the end of this post you'll know how to watch Star Wars A New Hope in ASCII art form (i.e. text based graphics)... So let's begin. Recently I found myself working on a legacy application such that I had to redeploy the multi-node application into in Infrastructure running in Azure. Two of the models communicate via a WCF binding over net.tcp. While I was operating under the impression that the firewall had been opened up to allow the communication I was a bit stuck on how to validate that the communication was working. So I wandered up to the networking area to chat with our Network Architect. As I often find, chatting with those who have an expertise different than your own requires patience and effort in the area of translation. Even though we both work in the IT field we each have our jargon to deal with, but the price of admission is well worth it. In just a few minutes of explaining my challenge I had been provided wi
Read more

.NET MSTest and DeploymentItem Attribute

Image
I was recently reminded that order of operation can byte you when trying to troubleshoot intermittent unit test failures. First, I’ll be the first to admit that if you want to avoid problems with unit testing it’s best to avoid any dependency outside of your actual code base, things like databases, API and even the file system are best avoided in execution of your unit tests. That last one, the file system, in some applications is really hard to avoid. If you happen to be using MSTest, a helpful attribute for your test is DeploymentItem. This particular attribute allows you to define a file within your unit test project assuming it’s marked as “Copy Always”. With this attribute in place you can then combine this with TestContext.DeploymentDirectory to find this sample file and then do what you need to do. In my particular case I was having an issue with the unit tests failing on the build machine but not locally. After stumbling around for a bit I finally feel back to t
Read more

Example of using LazyInitializer.EnsureInitialized

Image
When looking at making systems more efficient it's helpful to think about being lazy. A helpful tool in the .NET tool belt is the static class under the System.Threading namespace LazyInitializer. In particular this class contains a method  EnsureInitialized This method is very simple to use and provides a convenient way to ensure that an initialization is called only once based on the value of the target property already being populated. For example, if you need to load a file as part of the setting of values in an application you can use the EnsureInitialized method. The following is a derived example of using the class to illustrate the usage pattern. If you are having trouble viewing the below code you can use this link to view the gist github. https://gist.github.com/briannipper/ac2778ccd0d15b4ab217083331419ae7 using System; using System.Collections.Generic; namespace Example.EnsureInitialized { class Program { static void Main(string[] args)
Read more