Live data from Hacker News

Troubleshooting: A skill that never goes obsolete

autodidacts.io

121–130 of 141 posts

Re: Troubleshooting: A skill that never goes obsolete

#121

Earlier quoted context omitted.

I strongly and emphatically disagree on every point (I don't even know what your statement about runtime state and code even means actually, it just seems like a category error, but how do you even write code without being able to reason about runtime state? It just makes no sense.), but I understand there are people who love their debugger and I respect them. Basically the only time I pop open the debugger is when i…

If you are troubleshooting it probably is not your code. You probably have not got enough knowledge about the codebase to reason about everything, on a large system noone has.

That's a very good point. I never used the debugger so much as writing C++ at google where much of the stack is proprietary and far too large to internalize.

C++ is especially hard to reason about, though. The cognitive overhead of "running the compiler" in your brain is just staggering. Even scala doesn't feel that bad. Java code feels like building with LEGO in comparison—super, super easy to read and process.

Re: Troubleshooting: A skill that never goes obsolete

#122

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, som…

Have you found effective ways to market this skill?

Usually 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).

Re: Troubleshooting: A skill that never goes obsolete

#123

Earlier quoted context omitted.

> and it's damn near impossible to climb out of the pit I've dug for myself. By far the easiest way to do so will be to find another job. If you can't do this, yea, mentality will lock you in to positions you don't want to be in.

The problem is that the new employer looks for CVs of those who achieve flashy things not those who fix things. Fixing things only gets notices by coworkers and good managers.

Agreed that could be a problem. Seems like a benefit in disguise, though—such an employer is likely not to manage a product well.

Re: Troubleshooting: A skill that never goes obsolete

#125
post #98

Earlier quoted context omitted.

The code rarely resembles the runtime state of the system. Debuggers are an incredible shortcut almost all the time.

I use printf (or log messages, or whatever equivalent). Haven't found a need for more.

Same! I use the debugger when I'm really lost.

Re: Troubleshooting: A skill that never goes obsolete

#126

What I missed here was the importance of keeping careful notes as you go. What exactly happened when we constructed that weird input and commented out line 353? What hypotheses are we entertaining? Can we rule out any of them based on our evidence? It’s very easy to dupe yourself if you’re doing it all in your head.

https://www.autodidacts.io/troubleshooting/#write-it-down

Re: Troubleshooting: A skill that never goes obsolete

#127

Earlier quoted context omitted.

The more I hear about this book, the more I realize that I was way too young when I read it.

I read it at age 18 and thought, "I should go buy a motorcycle and ride it around. That's the answer." Then I read it at age 30 and thought..."Oh, that wasn't the point at all."

So then what is the point?

Re: Troubleshooting: A skill that never goes obsolete

#128

> Realizing that I spend more time troubleshooting than I do building or doing ... That's not good. The problem with troubleshooting is that it messes up with your reward system. After you fix a hard-to-debug problem, you feel a sense of accomplishment. Which would be ok, but the problem is that this sense of accomplishment is often time higher than it should be. You go home at the end of the day thinking "well, toda…

User credit_guy advocates for technical debt.

Not at all. I do a lot of troubleshooting myself. Throughout my career (2 decades) I was very often the guy who did the troubleshooting. I still am, and I'm quite good at it.

But I don't want to be known as the great troubleshooter in my team. I want to be known (and I am) as the guy who builds stuff.

Re: Troubleshooting: A skill that never goes obsolete

#129
post #24

> Realizing that I spend more time troubleshooting than I do building or doing ... That's not good. The problem with troubleshooting is that it messes up with your reward system. After you fix a hard-to-debug problem, you feel a sense of accomplishment. Which would be ok, but the problem is that this sense of accomplishment is often time higher than it should be. You go home at the end of the day thinking "well, toda…

My skill at troubleshooting has caused me to be the goto guy in every project, which lends great credibility and opportunities for leadership. Your pride in your troubleshooting skills isn't pride in a side-quest, it's pride in having a deep understanding of how systems work in general and in the specific. "Good troubleshooter" might not look great on a CV, but all of your coworkers naming you as the most valuable me…

>My skill at troubleshooting has caused me to be the goto guy in every project

I stopped trying to be that person because it came with too many costs. It wasn't that I didn't want to do it but that I wanted other people to be able to in my absence.

Re: Troubleshooting: A skill that never goes obsolete

#130
post #34

> Realizing that I spend more time troubleshooting than I do building or doing ... That's not good. The problem with troubleshooting is that it messes up with your reward system. After you fix a hard-to-debug problem, you feel a sense of accomplishment. Which would be ok, but the problem is that this sense of accomplishment is often time higher than it should be. You go home at the end of the day thinking "well, toda…

You get more credit for putting out fires you started than building something that doesn't catch on fire in the first place.

I remember a post here from someone who would leave deliberate problems in his otherwise reliable code then would swoop in and fix them when the customer discovered them. Apparently the customer loved him.

Personally I've seen people who struggled on a trivial problem get a strong rating from their manager afterwards.

Post reply on HN