Life as a technology professional is difficult enough as it is — from justifiably frustrated end users, an ever-growing plethora of products and vendors, the demand for wisely developed and cost effective solutions, and the constant threat of security vulnerabilities being exploited… there is barely time left in the day to document the incredibly difficult lessons we learned while troubleshooting.

While almost anyone with a pulse can doodle a diagram on a whiteboard or Visio and even the most blissfully ignorant of our industry can deploy most devices & applications by clicking “New… next… next… accept… next… next… Finish”, troubleshooting is a different story as it involves a real world application of the “Scientific Method” that we learned in primary school.

And you thought you would never use after school! Well, you should! Make your HS science teacher proud! By now, you might be wondering what I am getting at…

Have you ever Googled an error message? Don’t lie to me, but most importantly don’t lie to yourself. You have and so have I. And like me you have probably been guilty of taking terrible advice that you found on TechNet just because you were in a panic and under the gun to fix an issue and eager to… you know… get back to writing that documentation your boss has been after you for! (Or not)

So you broke enough things in your career (hopefully early on and hopefully not in a production environment) and eventually learned to proceed with caution while gathering information online related to troubleshooting.

I have consumed many quality help posts and guides in my career but never contributed much back into the realm of knowledge on the internet. The more I consumed over time, the guiltiest I felt.

Why wasn’t I putting any effort into documenting the resolution to issues that I have struggled with? I cannot blame less than ideal company cultures for this (although they can still be blamed for bad decisions… like Any:Any rules…). I told myself that I fixed the issue and that it was time to breath; but then I moved on to the next issue or project or meeting, never returning to review and refine my notes after sending clicking “Send” on the Root Cause email to management. Even the best and brightest of us find ourselves doing the same.

After hearing for years from my coworkers about how I should start a blog, I decided to take their advice. Of course, I realize that much of that encouragement was really just sarcastic response to the Wall of Text style emails I tend to compose (which have been known to put even the most ardent caffeine addicts to sleep).

Last year when I took the leap and started in business as a consultant, I purchased a domain name, email address and cloud storage — and a WordPress site because it seemed like a good idea at the time and why not? Then I forgot about it until it automatically renewed and billed my credit card. Why did I sign up for this again?!?! Ha! I could have used the money instead for some beautiful Americans Silver Eagles or Austrian Silver Philharmonics (fun fact: I am a big fan of silver coins as an investment and a hobby).

Coincidentally, after I finished my first (and as a responsible former caffeine junkie, my last) cup of coffee for the day… I was distracted from creating “artwork” in Visio (yes there is an artistic element to it and if anyone tells you otherwise they’re lying!) by a production issue. Having just reflected on and lamented the auto-renewal of my WordPress subscription, a lightbulb went “ding” in my head while a bell rang light (or was it the other way around?!?!)… I resolved that this would be my first blog post and I held myself to it.

*****Welcome to my blog!*****

These days most of my business is security related — to be specific, engineering and deployment. With an exponentially expanding dictionary of known security exploits for all types of systems and applications, there is a corresponding workload that is being generated. This is where I step in as an well-rounded and experienced systems architect & engineer — by grabbing these projects, large and small, and helping to translate between the technical aspect of security requirements and the actual line-by-line implementation of solutions which meet or exceed them. Whether it is helping to ask the right questions in order to help decide important technical details of configuration or being the guy who is implementing the changes at midnight or even taking and comparing/analyzing packet captures on every device between point A and B to troubleshoot an issue that stems from a security remediation/hardening activity… none of it is outside my comfort level. Oh and you can add Visio artist to that list (Incase you can’t tell, I love network diagrams because they can tell you more about an ecosystem than the Bible-sized books that we used to have to purchase and read before the Internet became the new standard for documentation).

Enough rambling. Time to create content.