Advice for Troubleshooting

1. Differential. Figure out what is NOT working (obviously) but also figuring out what IS working is just as important. In medicine they talk about "differential diagnosis". In general it's the idea that if we know what things depend upon to work, and we compare what IS working with what is NOT working, we can find the differences in what those things depend upon, and so find out what is wrong. To enable this... do LOTS of testing. Often. To see the pattern put the data in a table and stare at it.

2. Simplify. This is why we want to write tiny programs, or make one little change at a time and test it. When we have a very small bit of code, or a very simple process, it's much easier to see where it's going wrong. So if you had a big program that worked, and you make a small change, and test it again, and it doesn't work, your change probably caused the problem. (might be something else that changed and you didn't realize it). If you are starting with a big thing, and you have no idea what changed, start dividing the big thing up, simplify it, and find the source of the problem.

3. Divide and conquer. If you can run tests on different parts of the system, always run the test in the middle. Then if it fails, you know the problem is in the first half, and if it passes, you know the problem is in the last half. When you simplify, try to divide the big system into two smaller systems, about in the middle (if possible). This is called "binary search" and it's the fastest way to find the bug, if you can't do a differential on it.

4. Remember. Keep a log of the problems you have encountered, and refer to it when you run into a new problem, to see if anything seems similar. Always document what you do to fix things, and what you found out the cause of the problem really was. Collecting interesting causes of problems is a hobby. e.g. Javascript Debugging

5. Question your Assumptions. Most bugs come from some different between the thinking of the programmer writing the program in a language, and the thinking of the programmer who wrote the language. This boils down to what you thought you told the computer to do, and what it understood that you wanted it to do. So when you stare at the code that isn't working, ask yourself which parts of you might be assuming does "A" when it actually does "B". And then test those assumptions. If you can step though the code, as you can in the DevTools Console (Links to an external site.), you may see something unexpected happen.

6. Rubber Ducky. One of the most effective techniques for debugging is the rubber ducky. This is where you get up, walk away from the program to take a bath, and in the bath, you explain to the rubber ducky how the program works. Amazingly often, this will result in you explaining to yourself how the program does NOT work. Even better than the one in the bath, a "rubber ducky" who is also a programmer, and can ask questions about point out assumptions, remember when they made that error, help you narrow down the problem, simplify, and differentiate... well... that's the best rubber ducky of all. Which brings us to...

7. Ask for help. Ask a friend, or search and post on

https://stackoverflow.com/

and be sure to state what you think the problem is. "The fastest way to get the right answer on the internet, is to post the wrong answer."

8. RTFM LAST RESORT: Read the Documentation for the language, the keywords you are using, or, if you are calling functions or using objects you, or another, program wrote at some point in the past, whatever documentation they (you) wrote. I know it's demeaning. But it's still necessary sometimes to Read The Freaking Manual.

See also:

• https://programmerhumour.tumblr.com/post/181683074920/narrator-voice-it-did-not-magically-work-now
  

  .