Hi Nancy,

>Once I get to this point, btw, I'm not in debugging mode any more. I step >back, in this case, to design mode.

This is the key, here. So you keep DEBUG associated directly with coding, and not with design/discovery?


>Why is it important to make that distinction? I don't know about you, but >for a lot of us, there's a tendancy to do other things while debugging. >Like, you notice something in some code as you're looking for problem A. So >you change code, then you change what you originally meant to change for >debugging, then you test your code, and suddenly, it's different. You >unfortunately have tainted your investigation.

This became one of the debugging errors(!) I used to make. I've killed myself with this so many times that I classify this as completely incorrect behavior when bug-hunting. I've been trying to get into the habit of strictly avoiding this. Now if I see something I think should change, I add it to the task list. I try to allow no changes until the debug session is finished. The harder part is to make my associates understand this as well. Try catching a bug when someone else is modifying files dependant to the one you're debugging! Hard to track, especially if there is no source control to 'check out' the files with to keep them locked.

>I've found I get less distracted from my priorities, too, if I'm >methodical.

This is very true!


jfh