3.5.3 - Find and Correct
Once we’ve got a very clear idea of what we’re looking for, we can start to look through our source code. We shouldn’t have to look in many places; we’ve reduced the scope of where the problem could be to a single part of our robot code (see 3.5.2 - Identify the Issue).
This step is best done with multiple people, following the “rubber duck debugging” principle, which suggests that talking out loud and explaining what the code does is a successful tactic to spot flaws in its execution. Talking through the logic with somebody else does a few things:
If they’re not already familiar with the project (or this part of it), they become more knowledgeable about how the robot program works.
As you explain the code line-by-line, it becomes clear what the problem is right away. Hearing things aloud is one of the easiest ways to realize what was messed up. Plus, forcing yourself to explain your decision apparently leads to you saying something that you catch is incorrect.
The other person may see something you missed yourself, which helps solve the problem.
Correcting the problem
Once the issue is found, and a select portion of code can be pointed to for its issue, solving the problem is much more trivial. Simply write the code that should have existed, and test it. It’s hard to overexaggerate how much testing can help catch issues in your code soon.