On Mar 20, 2006, at 9:51 PM, Alex Martelli wrote:
> While what *I* want, ideally, is pair programming -- somebody sitting
> right at my side, alternating with me in controlling keyboard and
> mouse,
> and in verbalizing what he or she is coding -- that's part of the huge
> productivity boost I observe in a co-located team... that pair
> programming works SO much better that way, that even with the best
> remote cooperation tools (subethaedit onwards).
I've often noticed that programming for me is akin to composing
music. Now let me start by saying that while I can hum pretty well,
I'm not a musician of any sort, so this is based upon the experiences
related to me by others who are (btw, there seems to be a very large
overlap between programmers and musicians...).
I can be mulling over a particular problem for hours, sometimes
days, and do nothing but write some pseudo-code or a couple of trial
programs that don't really do what is needed. Then, at some
unpredictable point, clarity sets in and I see the solution. After
that, it's just a matter of transferring that into code (for which
Python is by far the best language, as it doesn't get in my way).
The people I know who write music tell me of a similar process: they
play a few bars or write a few words, but it doesn't feel quite
right. Then either a particular musical hook comes to mind, or a set
of words that solidifies the image of what they were feeling, and
after that the song is written in their head and just needs to be
transferred to tape (or bits, as is more common these days).
I can't wake up one day and plan my day like this: 9-12, write some
killer algorithm; 12-1, run errands and eat lunch; 1-3, add algorithm
to existing code and refactor; etc. Nor can the musicians I know plan
of writing the first stanza of a song in the morning, the second
after lunch, and the chorus in the evening.
The other similarity is that some musicians tend to be more creative
when off by themselves, while the rest seem to feed off of jamming
together with others. Most of them strongly prefer one or the other;
rarely do they employ both. The comparison to programmers would be
that I seem to resemble the former type, while you seem to resemble
the latter.
I strongly agree on the benefit of code review, though, especially
in my case where things tend to get written more or less
unconsciously. While the main problem may be addressed well, there
are either side/end cases that still need to be addressed, or there
is an opportunity to refactor to make it fit in much better with the
project as a whole. A partner who is not emotionally immersed in the
code can usually see these things better than the person who created
the code.
> Wanna talk debugging? I think solo debugging is even worse than solo
> programming -- when I just CAN'T have a debugging partner for a
> sufficiently nasty bug (race conditions are the worst, but there are
> many other categories vying for that title;-), I'll turn to one of my
> beloved plushies (I'm firmly convinced the baby tiger is by far the
> most
> effective debugging partner for most bugs, though Tux the Penguin
> has a
> knack for helping spot bugs that aren't MY fault but rather the
> compiler's &c -- since I've been using Python for most of my coding
> for
> years, poor Tux hasn't seen much action recently) -- I talk out
> loud to
> the plushy-partner to make narratives out of expected and observed
> occurrences. But a *LIVE* partner, actively checking out the
> coherence
> of my narratives and challenging them and proposing alternatives,
> is 10
> times more effective... the plushies don't even talk back (except in
> debugging sessions that have gone on for *FAR* too long;-).
OK, we part ways on the plushie thing, but here I have to agree with
you: a second set of eyes (and brain patterns) helps immeasurably
when debugging. I think the key here is having to explain what you
did and what you thought the code should have done to someone else
clarifies the problem, whether it's explaining it to someone else in
the room, or trying to explain it in an email to a list like this. I
can't even begin to count the number of times that I've been stuck,
and decided to post the problem to a list for help, and in the
process of composing the email, figured out what my mistake was!
Those netiquette guidelines for posting intelligently aren't to help
the readers of the post; they're to help you form your scattered
thoughts into a coherent picture, and more often than not, if it's a
bug that I've created rather than a gap in my understanding, the
process of writing the email is all I need.
I guess if there's a point to all of this, it's that good
programming is a creative process, and that you need to identify what
works and doesn't work for you. There is no one-size-fits-all
approach that is the "best".
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
--
http://mail.python.org/mailman/listinfo/python-list
