Live data from Hacker News

Troubleshooting: A skill that never goes obsolete

autodidacts.io

61–70 of 141 posts

Re: Troubleshooting: A skill that never goes obsolete

#61
post #47

Earlier quoted context omitted.

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

Based on the timestamps, it could only be. But this story, timestamps notwithstanding, was submitted by suprisetalk ~2 days ago.

Then it was placed in news.ycombinator.com/pool (https://news.ycombinator.com/pool?next=43176091), and got two comments; credit_guy's comment was one of them.

Then, today, it hit the frontpage.

Notice that if you mouse over "9 hours ago" on the story it shows the timestamp 2025-02-25. 9 hours ago was not 2025-02-25. If you mouse over the "7 hours ago" on credit_guy's comment, the timestamp shows 2025-02-26. One day after it was submitted, two days before it made the frontpage.

Re: Troubleshooting: A skill that never goes obsolete

#64

Earlier quoted context omitted.

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

The problem is that the real impact and the perceived value of each path are not necessarily the same. Building new things is sexy and highly visible. It's easy to say about yourself "I built that cool new feature" or better, to promote "I might build something of incredible value". You're front-and-center with decision makers, shaping the future. Conversely, debugging is perceived as a cost center. "I fixed that cri…

If your organization is like that then let them know. Suggest some leading indicators that they could track so you can take credit for your preventative work. If all else fails, then you can decide if you want to just do visible work or leave.

Re: Troubleshooting: A skill that never goes obsolete

#65

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

There is some truth to what you’re saying, but that’s just another example of (particularly American) capitalism’s masterful misallocation of resources when it comes to compensation.

Re: Troubleshooting: A skill that never goes obsolete

#66

> 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 spend way more time troubleshooting than I do building new things. I'm a lead programmer on my team. I regularly hop on impromptu zoom calls to help people out with thorny problems or jump into slack conversations. I don't get a lot of focused time for building new stuff. I'm more valuable to my team keeping them running smoothly and enforcing standards that avoid some of the nastier troubleshooting.

Re: Troubleshooting: A skill that never goes obsolete

#67
I feel like the way to think about troubleshooting is to think about it as an umbrella encompassing reliability and quality engineering in software. If you can find ways of showing how reliability and quality of a software can be broken and how it can be improved (simultaneously), then you have a career to make.

Don't wait for stuff to break and react. Be proactive and find ways to demonstrate how it can break and how to fix it.

Re: Troubleshooting: A skill that never goes obsolete

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

Or debugging and understanding the reason why a system isn’t behaving as expected. And pinpointing the part of the code that causes the behaviour that is not desired.

In another field—In IT Service Management (ITSM)—there is the distinction between incidents and problems. If you see many incidents coming in that are related, you sit down and start doing a root-cause analysis, basically a form of debugging. Or troubleshooting.

So yes, this is a skill that is timeless.

Re: Troubleshooting: A skill that never goes obsolete

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

Re: Troubleshooting: A skill that never goes obsolete

#70
post #35

Earlier quoted context omitted.

I think you may be leaning too far in the other direction. I'm a troubleshooter. I fix problems. I keep my head straight in a crisis. Every job I've had across 3 decades, regardless of my actual title or formal responsibilities, I'm the firefighter. People call me when they can't figure something out. People call me when something big breaks and needs to be fixed urgently. Even if I'm not an expert in the broken thin…

> I do not feel this has held me back professionally. I have been loved by management and peers in all of these jobs. If only your experience was universal in that regard! I once had that role in an early-career job -- but I was looked down upon by peers and management because I was doing mostly maintenance work. The "good" developers, in their minds, were the ones shipping the most new features -- the irony being th…

That's your problem. You keep the fixes for a rainy day when production is down and the business is losing $10m an hour.

>Yeah boss I can fix it, but how much is it worth to you since this isn't in my job description.

Post reply on HN