Teaching to debug
Teaching to debug
Our goal is that you try to teach students fishing instead of giving them the fish. In other words, your goal is to teach them the debugging process. To achieve this goal, please consider these suggestions:
Ask them “Have they tested the components independently? Does the LED/Button/Timer/UART/ all work as expected before we even incorporate any new logic?” Emphasize building the program on strong foundations. Making sure all your components are working properly is very important. You might copy/paste from another project and assume it should still work. Nevertheless, the clock for this new project could be different, or something in the setting could be different that causes the behavior to change. So, it is important to have basic test cases to check all the basic components you need for the project are working flawlessly. Generally, copy-pasting code from older projects and repositories should be done with care.
If they are dealing with a compilation error, have they googled the error and looked the lines of code above the compilation error and not just the line itself. A lot of times, the compilation error originates somewhere upstream and manifests itself further down in the code.
Ask students if they have paid careful attention to the warnings generated by the compiler. Some warnings point to a grave issue on the code. One such warning is "function declared implicitly," which basically means the function is not defined. Some warnings can show unintended assignments or type castings. It is important to check all warnings and decide which ones to ignore and which ones to address.
If you see students have very long spaghetti code, please help them break the code into smaller parts before helping them with debugging. Long functions are hard to debug and maintain. Functions should have small clear goals that are easy to test. If the student’s code is not well-organized and modular, you should spend their 10-minute giving them advice on how to break their code instead of debugging a poorly-organized code.
Ask them “What was the last thing that worked?” Basically, try to see when was the last time they compiled and ran the code. What functions they have tested and know for sure it works. Have they narrowed down to where the problem arises? If not, help them understand this process. Of course, this step assumes a relatively well-organized and modular code. However, a modular code, if it is not tested in small pieces is not helpful.
If you see students are struggling with pointers/structures or they are not using enum/macros effectively or they are not building their FSMs properly, please ask them if they ever debugged and experimented with the examples we worked in class:
If not, they should download them and experiment with them. You can go over these examples with them during their 10-minute time slot. Please avoid using their own project as a vehicle to teach these concepts as it might have several negative consequences.