Divisions of labor

[Robert Brewer]

Cameron Laird:
> This still leaves open the question of precisely what the
> alternative is--to have eager debugger-savvy friends?  I
> think there's more to it.  I'll likely return to this.

Jeremy Jones:
> Is it possible that this is a case of "what you don't know,
> you don't know that you don't know"?  Meaning, if you aren't
> (in this case) a debugger guru, you don't know how much (more)
> you would use the debugger for non-catastrophic bugs and how
> much more productive it would make you (again, for non-cata-
> strophic bugs, or things that aren't even bugs)?  All of
> programming isn't debugging...

True. Further, not all debugging is using a debugger. Far from it. Read
http://samizdat.mines.edu/howto/HowToBeAProgrammer.pdf for an
introduction to other aspects of debugging. I'd say the more important
aspects of "learning how to debug" are not which technique you use.

I've used logging, printlining, and debuggers quite a bit. Printlining
is my quick and dirty technique of choice while the product is in beta
or below. This includes letting exceptions propagate outward to get
stack traces printed. I only reach for pdb (or other debugger) in
multi-layered programs where I'm trying to quickly isolate the layer
responsible for a bug. That usually only happens when there's _no_
response from the running code (endless loops, for example). Once I've
isolated the problem area, it's usually back to printlining if the
solution isn't immediately obvious. But once you release, USE LOGGING.


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org