I like to think there are three methodologies people use to debug code that isn't working. They are:
The shotgun approach
Each iteration in the shotgun approach goes something like this: "My code is kicking up an error. I'll try changing fourteen different things and then see if I fixed it."
The scientific method
Each iteration of fixing the problem goes something like this: "My code is kicking up an error. I do several things like looking at log files, examining the circumstances of the error, collect a set of symptoms of the error, and write all these down. I examine the 'facts' that I have collected and formulate a theory on what the cause(s) might be. I fix the thing I think caused the problem and then I test to see if my change fixed the problem or not."
The get-someone-else-to-look-at-it method
Each iteration of this process goes something like this: "My code is kicking up an error. I ask on one of the chatlines for some help in fixing it."
The three processes are very different and each has their advantages and disadvantages.
The shotgun approach is good when you don't really understand what you're doing or if you have a hunch you can fix the problem quickly without doing a lot of work. The shotgun approach is bad if you need to do more than a few iterations of trying to fix the problem--in this case you should switch to a scientific method.
The scientific method is called the scientific method because it's the basic process that Science uses to formulate theories and prove them. (Note: the word "theory" has a completely different meaning in Science than it does in colloquial language.) The scientific method provides a controlled and very methodical approach to understanding the problem(s) and fixing it. The scientific method is rigorous and often takes longer to perform than the shotgun approach, but the results frequently involve a much better understanding of the issue and circumstances, code that is of higher quality, and less frustration experienced on your part.
The get-some-help method is great when you're in over your head--there's something about the problem you don't understand or can't examine because you can't see the code or there's not enough documentation. Because there's little work in the get-some-help method when someone hands you the answer, you learn less. Additionally, if you use this method often, people may become annoyed with you.
Use the methods when it's a good idea to use them.
If you find yourself using the scientific method often (and you should be), make a document template and formalize the process more. The template should have the following sections: one or two line description of the problem, the complete list of symptoms observed, and steps to repeat the problem. Then it should have a section for you to log all the theories you've tried, the fixes you've applied, and how those fixes affected the symptoms. With these details written down and out of your head, you're much more likely to be able to solve the problem faster than not writing them down. Additionally, it's much easier to get help and bring the person you're asking for help up to speed with what the problem is and what you've done so far to solve it.