Divisions of labor

Jeremy Jones zanesdad at bellsouth.net
Wed Sep 22 20:25:45 CEST 2004

Cameron Laird wrote:

>In article <1gkiywn.1ydvxr62u3q0dN%aleaxit at yahoo.com>,
>Alex Martelli <aleaxit at yahoo.com> wrote:
>			.
>		[much that deserves comment]
>			.
>			.
>>This is a reflection I had as a consequence of this episode.  But if I
>>meet about two "super-horrible bugs" a year, and a perfect debugger
>>would save me 3 days or so in each case, I need to find one that I can
>>learn to use with perfect skill in less than 6 days, and keep
>>well-trained on at no cost.  Half the incantations that WingIDE guru was
>>incanting were completely lost on me and the other guy helping us out in
>>that debugging -- if I took a week to learn it, and then didn't have any
>>need for it for months, I'd have to relearn it again 7 months later...
>>not a net win.
>>I was highly skilled back when I had to use MS Visual Studio to develop
>>and debug C++ code -- but it's the kind of skill my brain expunges as
>>fast as it possibly can, as soon as it becomes unused (as opposed to,
>>say, weird interesting facts about languages and libraries I may not
>>have used for years -- THOSE, for me, tend to stay around somewhere in
>>my brain!-)
>			.
>			.
>			.
>I made almost exactly the same calculation, and certainly
>came to the same conclusion.
>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.
I hope that my following comments don't sound presumptuous or 
antagonistic.  This topic really interests me and I'd like to raise a 
couple of questions about the above discussion for my own sake.  Let me 
assert up front  that I am _far_ from a debugger guru.  I'm just 
starting to tinker around with it lately.  My previous debugging 
techniques centered around a bunch of "print" statements or log entries, 
etc - but, I must say, they were fairly effective.

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-catastrophic bugs, or things that aren't even bugs)?    
All of programming isn't debugging, so becoming a master of the debugger 
to the detriment of some other aspect of programming (which Alex could 
fill in here with much more finesse than I could) is, in my opinion, a 
mistake.  But I just wonder how much I'm missing by not being as 
proficient with the debugger.  I guess the same could be said regarding 
other tools - maybe even <duck> IDEs <run>.

Another question that I'd like to raise is, does a one week investment 
in time necessarily add up to one week in time?  Meaning, if you 
determine that you would like to become more adept at the debugger and 
decide that you're going to spend your spare moments with it when things 
are slow and there is little/nothing to do anyway, do you really have 
anything invested in it compared to your productive activities?  
Especially if the spare moments (which would have been spent surfing 
Slashdot) result in an improvement of productivity immediately.  I'm not 
asserting that this is the case - just raising the question.

Anyway, hope I don't sound like a butt on this.  Both of my questions 
are, interestingly, non-quantifiable.  I guess I can empathize with 
Cameron's statement:

I have an intense interest in this narrative, and little
ability yet to articulate why.

I dunno.  Maybe it's because I just started fumbling around with pdb and 
this topic just struck a chord within me.  Maybe it's because I've got a 
personality flaw where I'm willing to "waste" spare time on learning 
things that I feel _may_ (not _will_ - _may_) help me think in different 
ways.  Currently, I'm on a kick of wanting to "get" functional 
programming.  I don't know why, but I just feel like when I "get" it, 
it'll help me think about other things in different and better ways.  
Maybe that's just Eric S. Raymond's comments on Lisp floating around in 
my head - or maybe David Mertz's articles on functional programming.

Jeremy Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20040922/e157c213/attachment.html>

More information about the Python-list mailing list