#General Debugging Techniques
##Reproduce It The first step is to find a way to reliably reproduce the problem, document the steps. Often doing this alone will give you a good indication of where the problem might originate. If you have a reproducable procedure that only works some of the time it is likely you have a race condition somewhere in your logic.
##Up-to-date Second step should be to confirm you are inspecting the latest code. Did your changes really get uploaded to your development instance? Are you absolutely sure you are editing the correctly file(s), not a similarly named or overridden file?
##Inspect Error Logs Often the problem is already being reported, whether server-side or client-side console errors.
##RTFM If you are using API's you didn't write, then read the documentation. Sometimes it takes a few readings to really get everything to sink in. You may also need to set up a separate small test of the API's, essentially QAing them against all possible use cases your logic may throw at it -- don't assume the documentation is correct, if there is any.
##Check Inbound Data If your logic depends on data, don't assume you are working with valid or expected data, triple-check it!
##Walk Backward Walk backward through your logic from bug execution on back to find where the problem originates. This gives you a fresh perspective and gets you to the cause quickly if it's caused by recent logic.
##Walk Forward Use breakpoints, or console prints outs of related data so that you can see what is causing transforms and what those transforms are when the logic executes. When debugging, never take anything for granted, for example add a console log to each if condition state so you can verify which condition is really being met.
##Compare Compare diff of working vs. non-working. If you have some sort of version control this can be a great way to narrow down what LOC might be causing or attributing to the problem.
##Process of Elimination Sometimes you can't tell what is causing an issue, removing chunks of code one at a time can sometimes help you find where a problem is originating. Progressively take one thing out at a time. An example is removing a javascript include from a third-party service, making sure they are not injecting anything.
##Prototype A broken feature in a large application can sometime be unweildy to test, and at times it's possible to extract the feature and test it independantly of the rest of the application, however this may have additional unintended consequences.