Debugging - How can I debug my program? - Part 3

Make it all fail and make it fail fast

Make it all fail :

As part of this, it is always important to verify that our code is “plugged in”, that is, that we are actually exercising the problem that we think we are. Every programmer has spent hours chasing a bug, only to realize that they were actually calling their code on the wrong dataset or with the wrong configuration parameters, or they are using the totally wrong version of the software.

Mistakes like these are particularly likely to happen when we're tired, frustrated, and on a deadline, which is one of the reasons late-night (or overnight) coding sessions are almost never worth it.

Make it fail fast :

If it takes 20 minutes for the bug to appear, we can only do three experiments per hour. This means we'll get less data in more time, and we're more likely to get distracted by other things while waiting for our program to fail, which means the time we're spending on the problem is less focused. Therefore, it is critical to make it fail quickly.

In addition to making the program fail quickly in time, we want to make it fail quickly in space, that is, we want to locate the fault in the smallest possible region of the code:

The smaller the difference between cause and effect, the easier it is to find the connection. Many programmers therefore use a divide-and-conquer strategy to find bugs, i.e. if a function's output is wrong, they check that things are right in the middle, then focus on the first or second half, and so on. against.

N things can interact in N! different ways, so every line of code that doesn't run as part of a test means more than one thing we don't need to worry about.