3 ms·
Troubleshooting is one of my main comparative advantages - I'm better at it than I am at programming and I enjoy it more. It's also a relatively independent ski
by homefree 2y ago
Troubleshooting is one of my main comparative advantages - I'm better at it than I am at programming and I enjoy it more. It's also a relatively independent skill, not everyone is good at it or likes it. It reminds me of the lateral thinking puzzles I did as a kid where you had to ask questions to uncover whatever the weird situation was. You have to question your assumptions - think about how you might be wrong, something I like to do in general anyway.
There's a certain way of reasoning about the problem and thinking about what it might be with limited information in a systemic way. It's also a bit broader than debugging - you can do a lot of troubleshooting (sometimes faster and more effectively) by doing things other than reading the code.
It's also been somewhat of a career advantage because it seems to be both more uncommon than standard dev for someone to be really good at and something that most people dislike (while it's my favorite thing to do). It also overlaps a lot with other more general types of problem solving.
Anyway - a lot of the article resonates with how I think about it too.
- sandinmyjoints 2y agoHave you found effective ways to market this skill?
- homefree 2y agoUsually it’s best in an operational type role, can be support, sre, tpm, etc. depending on your strengths. It’s best when paired with good comms and somewhat good social skills. You build credibility by jumping in and doing a lot of support type stuff early on (which then also makes you better at whatever the product is, more familiar with what sucks for users).
- upcoming-sesame 2y agoThe parent comment mirrored my sentiments exactly. In my company, I'm often the person who joins a production bug troubleshooting call, after sometimes hours of investigation, and rapidly identifies the root cause. My typical workflow is: * Clarify the issue and our assumptions. Often, simply restating the observed behavior aligns everyone. * Pose questions to validate or challenge those assumptions. * Suggest alternative methods to test the primary hypothesis. Often, testing the initial hypothesis reveals its inaccuracy, leading to a swift discovery of the actual root cause. Ultimately, it comes down to critical thinking and questioning assumptions I think.
- samuell 2y agoI think troubleshooting has a lot of overlap with thinking along the lines of the scientific method. 1. You have to start having hypotheses that you test, but should be ready to throw them away as quickly as you thought of them, when the results from testing it says so. Let data 2. You should preferably think hard about effective way to quickly rule out influencing variables and so quickly square in on the area where the erroneous effect is coming from. 3. You have to really rule out confounders. Make sure to turn off any caches or similar that might play games with you. The area where I see most colleagues fail in this process is not being stringent enough with things like ruling out confounders and being systematic about organizing the outputs from hypothesis testing, to make sure you are 100% which outputs belong to which inputs etc. It is the discipline and strictness in the process that will do the trick. Anything less and you will just trick yourself.
- homefree 2y agoYes! This generally rings true to me. The other thing I see trip people up is being unwilling to make a fast hypothesis that can be easily tested to narrow scope. Instead they’ll often try to look at the code to understand but that’s usually slower for anything remotely complex.