People often seem incapable of solving basic problems with their computers. Here is a general strategy I use when handling computer problems. It's not the whole story, as you also need to have a reasonable model of how a computer works.
- Cut the problem: show that the problem lies on one or other side of some barrier such as the network subsystem. Iterate.
- Localize the problem: e.g. show that only programs using sudo don't work. Here you are trying to form a model of how the problem occurs.
- Test your hypothesis manually: edit files manually to see if you can fix and recreate the problem. Maybe your hypothesis is wrong, go back to step 1 and refine more.
- Restore correct operating conditions: fix the files in question so that the automatic/gui tools work again.
- Submit bug report: make sure that the next 'you' that comes along doesn't do the same work over.
Step 1 is obvious to people who have studied algorithm design - divide and conquer. Cut the problem in half repeatedly and you only take a logarithmic number of steps to solve it. A lot of people (most commonly on Windows and MacOS) instead prefer to randomly click options on and off, rerun commands and generally just panic about things. This rarely fixes the problem, and when it does, you have no idea what you did that fixed the problem (leading to a kind of computer superstition, or even a sort of subconscious avoidance pattern).
Steps 2 and 3 are a classic scientific method - model a problem, then try to disprove it. The disproving step is actually the most important. You might show that a problem happens when you perform some action, and therefore hypothesize that that action is the cause of the problem. But it may actually be caused by something orthogonal - perhaps the increased load causes the problem. To disprove it, find an alternative way to trigger the same action, or replace a pathway with a different one and see if the problem is fixed.
Some people (myself included) are loath to perform step 4 (ah well, it works now). This is foolish, as such sloppy repairs will break in the future and make things much harder to debug (I upgraded my machine and it all broke and now I can't log in to fix things). A similar problem is faced by people who rely on rebooting to solve problems. A bug is rarely fixed by reboot, and will come back at a less opportune time, and when you have forgotten what code was involved.
A lot of people don't bother with step 5. They think that this saves them time, but my experience is that it doesn't. This is for two reasons, firstly, it is a selfish act. If everyone did not perform step 5 we would not make progress towards a better world. But non altruistically, often our debugging is not as accurate as someone else. By submitting a bug report you are performing steps 3 and 4 in a distributed manner increasing the chance that the true bug is found. This can quickly and accurately pinpoint the exact problem, rather than a symptom.