It's a useful skill, but not a good career move. Early in my career, I used to fix bugs in a mainframe operating system. When I took a new job, I was given two stacks of paper crash dumps, each six feet high. I had to figure out what had caused each crash with paper and pencil, then fix the assembly code. It took me about a year to get the mean time to failure of the OS from a day to a month.

Often, you can't find the problem, but you can find a point where checking code will trap the problem earlier. Slowly, crash by crash, you work backwards to the source of the problem. Eventually you can find the root cause.

I got out of that after a few years and into the more theoretical end of computing, including proof of correctness. It was useful, though, to learn what makes software unreliable from the bottom.

(This is part of why I'm so down on unsafe code in Rust. Rust has a good safety system. There are people with an attitude that "I'm so l33t I don't need the checking." They're not. They may create something which imposes a safety constraint on the caller, and later, someone else violates that constraint and creates a memory corruption bug. They write code which has an implicit undocumented invariant which is violated when someone else makes a later change. Those are bugs waiting to happen.)