Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Troubleshooting: A skill that never goes obsolete

autodidacts.io

Post reply on HN
Print view View original

91–100 of 141 posts

Re: Troubleshooting: A skill that never goes obsolete

#91

Post by ForTheKidz »

fennecbutt wrote: post #90

I feel like the article is just a very long-winded way to say what I try to help junior devs understand and that's: take a step back and start from the very top, change only one thing at a time, don't become fixated. So many issues turn out to be the smallest configuration mishaps, this is why I also promote using a debugger as much as I can as well - there's nothing quite like being able to see _exactly_ what's goin…

> this is why I also promote using a debugger as much as I can as well - there's nothing quite like being able to see _exactly_ what's going on.

I don't know, the speed of just reading code and maybe inserting some diagnostic messages is hard to beat. It's a pretty bad day if I feel like I need to bust out a debugger—99% of "seeing _exactly_ what's going on" is not going to be relevant and will just distract you.

Re: Troubleshooting: A skill that never goes obsolete

#92

Post by ForTheKidz »

credit_guy wrote: post #3

> 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 are becoming complacent.

I think that's just having a job. There's nothing inherently better about building than fixing. Hell, anyone can build something these days. You can get chatgpt to write you a fully functional bootloader without knowing a single bit of assembly or how booting operates. Being able to grasp and fix things is already the superlative talent worth hiring for.

> But reliable car mechanics don't get paid a lot.

The equivalent in our industry is worth a lot more money than someone who can only build. I think "building" is a lot closer to your analogy of using a word processor than "fixing" things is and you've got the reputation of the two skills completely swapped.

Re: Troubleshooting: A skill that never goes obsolete

#93

Post by EvanAnderson »

I_dream_of_Geni wrote: post #77
steveBK123 wrote: post #55

Earlier quoted context omitted.

I've found past a certain point career-wise, troubleshooting really can't be taught. It's sort of a a mindset/attitude to me. I you are 5+ years into your career and haven't gotten there, you probably just don't care. It's the attitude of a developer who is indifferent to the craft and just wants to cobble together found code as quickly as possible to move onto the next thing. A good troubleshooter can enable higher…

"troubleshooting really can't be taught" Exactly: it is a gift. You have "the Knack". (Dilbert - The Knack "The Curse of the Engineer")

I think it has to do with interests. Some people have an inmate interest in how stuff works, and specifically how it breaks.

I think you can teach someone to troubleshoot in a procedural and methodical manner, but they will always lack the creative "spark" that comes from being actually interested. Procedural troubleshooters are useful, but they won't exceed the bounds of the model they've been taught to work under.

Re: Troubleshooting: A skill that never goes obsolete

#94

Post by ForTheKidz »

dblohm7 wrote: post #35
sjsdaiuasgdia wrote: post #8

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 just poor management, IMO. The good ones will have your number in their cell phone to call when the stuff they shipped breaks (or even better, allow you to take the time you need to not ship broken code to begin with). Plus it doesn't take much time in the industry to realize that shipping a broken product is a far worse look than shipping slower, and that the faster you can fix a broken product the less money you'll bleed.

Re: Troubleshooting: A skill that never goes obsolete

#95

Post by ForTheKidz »

xerox13ster wrote: post #6
credit_guy wrote: post #3

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

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

Re: Troubleshooting: A skill that never goes obsolete

#96

Post by davidmurdoch »

ForTheKidz wrote: post #91
fennecbutt wrote: post #90

I feel like the article is just a very long-winded way to say what I try to help junior devs understand and that's: take a step back and start from the very top, change only one thing at a time, don't become fixated. So many issues turn out to be the smallest configuration mishaps, this is why I also promote using a debugger as much as I can as well - there's nothing quite like being able to see _exactly_ what's goin…

> this is why I also promote using a debugger as much as I can as well - there's nothing quite like being able to see _exactly_ what's going on. I don't know, the speed of just reading code and maybe inserting some diagnostic messages is hard to beat. It's a pretty bad day if I feel like I need to bust out a debugger—99% of "seeing _exactly_ what's going on" is not going to be relevant and will just distract you.

Depends on the platform. Using a JS debugger is so easy, yet few devs I know use it.

Re: Troubleshooting: A skill that never goes obsolete

#97

Post by ahoka »

mrayycombi wrote: post #86

Brendan Gregg's USE method is for performance troubleshooting but could work in any situation (broken is just the worst performance, right?) https://www.brendangregg.com/usemethod.html

He promotes many more methods , based on the exact needs:

https://www.brendangregg.com/methodology.html

Re: Troubleshooting: A skill that never goes obsolete

#98

Post by MrDarcy »

ForTheKidz wrote: post #91
fennecbutt wrote: post #90

I feel like the article is just a very long-winded way to say what I try to help junior devs understand and that's: take a step back and start from the very top, change only one thing at a time, don't become fixated. So many issues turn out to be the smallest configuration mishaps, this is why I also promote using a debugger as much as I can as well - there's nothing quite like being able to see _exactly_ what's goin…

> this is why I also promote using a debugger as much as I can as well - there's nothing quite like being able to see _exactly_ what's going on. I don't know, the speed of just reading code and maybe inserting some diagnostic messages is hard to beat. It's a pretty bad day if I feel like I need to bust out a debugger—99% of "seeing _exactly_ what's going on" is not going to be relevant and will just distract you.

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

Re: Troubleshooting: A skill that never goes obsolete

#99

Post by autonomousErwin »

credit_guy wrote: post #3

> 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 think I know what you mean, in an ideal world - we wouldn't have bugs. You'd build a feature and it would work forever but that's rarely the case.

I think of it as "offensive" and "defensive" building, ideally you want to be on the offensive (i.e. building stuff that wasn't there yesterday) but you have to balance it with good defence (i.e. adding a certain type of anti-fragility to your system by fixing bugs due to your features being exposed to the real world).

Saying this, I've never met a good engineer who wasn't very good at troubleshooting so perhaps it's more of a consequence of building than a skillset.

Re: Troubleshooting: A skill that never goes obsolete

#100

Post by sevensor »

RedNifre wrote: post #51

What do you think will be the last skills/jobs to go obsolete? I think it's "Wanting the right thing" (This includes figuring out what the right thing is) and "Being able to articulate your wish clearly" (This includes clarifying your thoughts).

Are there people with those skills today? They seem to be in terribly short supply. I’ve seen more than one company spin its wheels for ages because nobody could clearly express an operational vision.
Post reply on HN