How to really learn from debugging
2006-1-27
Everybody who has ever done any kind of programming knows the wild hunt for the cause of an error. You change a thing here and try. Same effect. Chage something there. Try. Same problem, but now also something is wrong there. Change back, try this route. Repeat until the problem is gone. Properly done with a good staretegy this is called "debugging", but very often we get so caught up in trying this and that until it somehow magically works. Sometimes this process is so long and the path so twisted with so many false starts and deadends that in the end we no longer know what exactly the resolution was. What actually caused the problem, and how can we avoid it in the future? Here's some ideas about how to learn, really learn from debugging:
- Don't stop when the problem is solved, or when it "went away" - reflect on the original problem. See if you can pinpoint the cause and how your solution fixes that.
- If you have a fix, go back to the original code and see if you can re-apply your solution - This way you make sure of two things: Your fix is actually THE fix. And you mentally retrace the real solution. While debugging you might have tried a myriad of dead ends, found a multitude of "possible solutions". Make sure you remember the right one. The real one. The one that works.
- Celebrate the right solution - this step reinforces the storage and proper tagging of the one solution that works.
- Make sure you flush all false ends from the code (and your mind) - Debugging often leaves a lot of "helper code" behind. Things you tried to solve differently thinking this code might be the culprit. Make sure in the end only those parts stay changed that actually needed changing. That's why I recommend going back to the original code once a solution is found and re-applying the fix to that. That way you make sure you don't leave any false-end changes behind.
I'm sure that list can go on for some time. But my main point really is: make sure you are aware of the actual fix and remember only that. Make sure you leave only the changes that actually fixed the problem in your code.
Here's what inspired this post: I was just debugging an AJAX app that suddently no longer worked in IE but everywhere else. I commented things out to find the actual point things broke, re-wrote portions of functions I thought might have broken etc. In the end I discovered what had caused all the trouble: a HTML closing tag was missing it's '>' bracket. In Safari and all Mozilla based browsers this was no problem. But in IE this lead to a situation where the following HTML element never appeared in the DOM. And that element was crucial for my code. So there really was nothing wrong with the JS I was debugging. I could have left it the way it was! But in the meantime I had developed so many "possible solutions" I really needed to make the mental leap to flush them all out. I needed top realize and focus on the fact that unclean HTML had cause this, not bad JS code.
Similar
- using Tinderbox notes for templates?
- How not to whine
- Time spent on a project
- when do you want something the most?
alles Bild, Text und Tonmaterial ist © Martin Spernau, Verwendung und Reproduktion erfordert die Zustimmung des Authors
Martin Spernau
© 1994-2024
amazon.de Wunschliste
Facebook me!
Google+
Older Archives on Tindertraum
powered by Traumtank