Troubleshooting: The Skill That Never Goes Obsolete — The Autodidacts

If you build software you also run software, and if you run software that stuff is going to break, guaranteed. And when it does you jump in and start troubleshooting. Historically the great troubleshooters in technology teams were your ops teams, but these days everyone needs troubleshooting skills. I often have heard grizzled vets in tech shake their heads when seeing more junior engineers troubleshoot. It is a skill that is often learned in the crucible of a problem. It is mostly taught through apprentice-like functions. This post does a good job of breaking down the components.

I'll define troubleshooting as systematically determining the cause of unwanted behaviour in a system, and fixing it.

Troubleshooting is often learned tacitly, in the process of explicitly learning "the skill". Troubleshooting is rarely discussed as a skill unto itself. But many features of an effective approach to troubleshooting are domain-agnostic.

Realizing that I spend more time troubleshooting than I do building or doing, and that the skill of troubleshooting can be honed separately from the domain it's applied to, I decided to try to figure out how to improve my troubleshooting skills -- and as a result, my effectiveness in multiple domains.

Learning troubleshooting as a skill, a discipline that you can refine over time, will benefit anyone working in technology. And probably other careers too…