TITLE: Honest Answers: Debugging
AUTHOR: Eugene Wallingford
DATE: March 08, 2013  3:50 PM
DESC: 
-----
BODY:
We have all been there:

<BLOCKQUOTE><EM>
Somehow, at some point in every serious programming project,
it always comes down to the last option: stare at the code
until you figure it out.  I wish I had a better answer, but
I don't.  Anyway, it builds character.
</EM></BLOCKQUOTE>

This is, of course, the last resort.  We need to teach students
better ways to debug before they have to fall back on what
looks a lot like wishful thinking.  Fortunately, John Regehr
lists this approach as the last resort in his lecture on
<A HREF="http://blog.regehr.org/archives/199">
   How to Debug</A>.
Before he tells students to fall back to the place we all have
to fall back to occasionally, he outlines an explicit,
evidence-driven process for finding errors in a program.

I like that Regehr includes this advice for what to do after
you find a bug: step back and <EM>figure out what error in
thinking led to the bug</EM>.

An important part of learning from a mistake is diagnosing why
you made it, and then taking steps wherever possible to make it
difficult or impossible to make the same mistake again.  This
may involve changing your development process, creating a new
tool, modifying an existing tool, learning a new technique, or
some other act.  But it requires an act.  Learning rarely just
happens.
-----