I first do the whole "Ockham's Razor" thing. Usually, the answer is right in front of me. A common mistake that I make, is that I may have a variable that is being redeclared inside a loop, so I don't realize the value isn't stable, or isn't being sent out to the enclosing context.
Those kinds of things usually fall to a quick look-see.
Next, I Google. Usually, a StackOverflow or Apple Development Community answer shows up. 99% of the time, that solves the issue quickly.
I also have the issue of "I know how to do it, but do I know how to do it correctly?" The Google thing often helps with that. StackOverflow has a lot of folks that are obsessed with correctness, and I have learned valuable lessons from them.
But hardware-wise, 99% of my problems are bad cables. Seriously. 99% of the problems that I've encountered. It's crazy how bad cables are the bane of civilization. Most pro IT techs I know, never reuse cables. They'll toss out dozens of cables, in great shape, as opposed to reusing them.
I was originally trained as a technician, and troubleshooting is what techs do. Things like "divide and conquer," and "export status along the pipeline" are good ways to zero into an issue. Debugging software can be a lot like debugging hardware. I learned on microwave RF tech, and software is a breeze, compared to that.
Failing everything else, taking a break, and watching a junk TV show for an hour, often helps.
I don't know if I have ever encountered an issue that I haven't been able to solve, eventually.
Sometimes, "solving" an issue, is done by evaluating whether or not it actually is an issue. For example, I may be busting my butt, trying to get a whacky bit of UI working, and some knucklehead will take one look at it, and say "Why are you trying to do make it work? It shouldn't even be displayed."
At that point, it's like those Bugs Bunny cartoons, where Bugs' head turns into a jackass.
1. Think about any unwarranted assumptions you might be making about context. Is there some environment variable that needs to be set that has become unset or had its value change? Did the OS version change? Some config file?
2. If you can find a working version of whatever it is you're trying to fix, do an incremental search to find the differences between that and the broken version. If everything is in version control this is easy. If not, incrementally change the working version to be more like the broken version until the working version breaks. (This technique is especially useful when dealing with large legacy code bases that you are not intimately familiar with.)
This is good stuff. One of the most maddening habits I've ever encountered is people who start going down the path of solving the problem, them hit some dead end, then ask for help at the dead end. Usually the answer is to walk back to the original thing you were attempting and find a different path forward that you missed.
Those kinds of things usually fall to a quick look-see.
Next, I Google. Usually, a StackOverflow or Apple Development Community answer shows up. 99% of the time, that solves the issue quickly.
I also have the issue of "I know how to do it, but do I know how to do it correctly?" The Google thing often helps with that. StackOverflow has a lot of folks that are obsessed with correctness, and I have learned valuable lessons from them.
But hardware-wise, 99% of my problems are bad cables. Seriously. 99% of the problems that I've encountered. It's crazy how bad cables are the bane of civilization. Most pro IT techs I know, never reuse cables. They'll toss out dozens of cables, in great shape, as opposed to reusing them.
I was originally trained as a technician, and troubleshooting is what techs do. Things like "divide and conquer," and "export status along the pipeline" are good ways to zero into an issue. Debugging software can be a lot like debugging hardware. I learned on microwave RF tech, and software is a breeze, compared to that.
Failing everything else, taking a break, and watching a junk TV show for an hour, often helps.
I don't know if I have ever encountered an issue that I haven't been able to solve, eventually.
Sometimes, "solving" an issue, is done by evaluating whether or not it actually is an issue. For example, I may be busting my butt, trying to get a whacky bit of UI working, and some knucklehead will take one look at it, and say "Why are you trying to do make it work? It shouldn't even be displayed."
At that point, it's like those Bugs Bunny cartoons, where Bugs' head turns into a jackass.