Remote teamwork anecdotes

[Ed Leafe]

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