Live data from Hacker News

Troubleshooting: A skill that never goes obsolete

autodidacts.io

41–50 of 141 posts

Re: Troubleshooting: A skill that never goes obsolete

#41

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

  > reliable car mechanics don't get paid a lot.
Actually, they do. It's the unreliable car mechanics that need to swindle.

Re: Troubleshooting: A skill that never goes obsolete

#42

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

I'm not sure that I agree with this, not that I'm big on troubleshooting, but experienced SREs (Site Reliability Engineers) are worth their weight in gold and get paid an insane amount of money. Perhaps the key is to debug a vendor's solution rather than an in-house one.

Re: Troubleshooting: A skill that never goes obsolete

#43

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

Re: Troubleshooting: A skill that never goes obsolete

#44

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

> reliable car mechanics don't get paid a lot. Actually, they do. It's the unreliable car mechanics that need to swindle.

Reliable mechanics have high rates and long waits everywhere I've lived.

Hell, I've seen some that are so busy that they won't take new customers!

Re: Troubleshooting: A skill that never goes obsolete

#45

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

This is a fascinating take. I have been thinking about your comment for two days.

I think you're right in some cases (when working in a field one has mastered, for example), and I think I could probably go in the direction of getting it right the first time.

But the way I see it, any time I'm doing something new or innovative, I'm doing something I don't know how to do, which takes trial and error; and troubleshooting is basically figuring things out by trial and error, in a systematic way.

Though a lot of time it is used for fixing bugs, I think troubleshooting as a skill and mindset is equally useful for creating new things, where you are solving for something.

Re: Troubleshooting: A skill that never goes obsolete

#46
post #10

Earlier quoted context omitted.

> But could you have built a new feature that would roll out to 50% of users in that same time? No.

If the impact of debugging is expected to be larger than building something new, then debug. Else, build something new.

More like: why fix a 5% bug when you can deploy a new bug to the other 50%

Re: Troubleshooting: A skill that never goes obsolete

#47

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

This is a fascinating take. I have been thinking about your comment for two days. I think you're right in some cases (when working in a field one has mastered, for example), and I think I could probably go in the direction of getting it right the first time. But the way I see it, any time I'm doing something new or innovative, I'm doing something I don't know how to do, which takes trial and error; and troubleshootin…

time dilation

Re: Troubleshooting: A skill that never goes obsolete

#48
post #32

Earlier quoted context omitted.

This mentality through most of my career has left me trapped as technical support, and it's damn near impossible to climb out of the pit I've dug for myself. What you say about being seen as a car mechanic is true.

I feel this way about documentation. I do it, a lot. I get compliments and positive feedback on it. It helps me remember things I would otherwise forget. I hope that others would be inspired by my example but it hasn't happened. I could be selfish and horde my own documentation and let others sink or swim. But that hurts me too as I'd have to pick up their slack.

I'm reminded of the Gervais Principle. Doing the work is not the way to "win," but not winning might be the better lifestyle. Depends on your motivations, aspirations, and ethics. It's easy to chase the total compensation number, because it's just _there_ and like what are we doing anyway? But then what are you doing, anyway?

Re: Troubleshooting: A skill that never goes obsolete

#49
> Don’t assume it’s complicated

There are problem areas where it is a lot easier to assume everything is a 10/10 monster.

If you start every journey with "power cycle the device" and always wind up with a bridge call between 3 vendors, you might as well get the bridge warmed up the moment something throws a warning.

Oftentimes, getting someone on the phone can be a bit of a circus act regardless of what the contracts say. Over reacting early on can minimize total time to resolution.

Re: Troubleshooting: A skill that never goes obsolete

#50
post #32

Earlier quoted context omitted.

I feel this way about documentation. I do it, a lot. I get compliments and positive feedback on it. It helps me remember things I would otherwise forget. I hope that others would be inspired by my example but it hasn't happened. I could be selfish and horde my own documentation and let others sink or swim. But that hurts me too as I'd have to pick up their slack.

I'm reminded of the Gervais Principle. Doing the work is not the way to "win," but not winning might be the better lifestyle. Depends on your motivations, aspirations, and ethics. It's easy to chase the total compensation number, because it's just _there_ and like what are we doing anyway? But then what are you doing, anyway?

That's been my career mindset. I've been in roles where my management has referred to me as a "rockstar" and it was a burden not a compliment. I'd rather be in a supportive team environment where everyone carries their own weight.

Compensation has been decent with this approach over the years. I could have made more staying longer in a darwinian bigco but the work was not fulfilling.

Post reply on HN