Defending the Python lanuage...

[Cliff Wells]

On Fri, 01 Feb 2002 08:29:42 GMT
Alex Martelli wrote:

> Peter Milliken wrote:
>         ...
> > Actually, if you are *good* at what you do, then code review, whilst
still
> > beneficial, is not nearly *that* beneficial. Things like code review
(IMO
> > :-)) is there for the 25-50% of programmers who just plain shouldn't be
in
> > the industry - what they generate is just absolute garbage - code
review
> > will hopefully stop the code from getting into Unit test and beyond the
> > point of redemption :-).
> 
> I disagree.  Code review, or even better the "continuous ongoing code
> review" that's such a substantial part of the benefits of pair
programming,
> is in my experience just as beneficial with the best coders: without it, 
> besides bugs, it's far too much a temptation to pepper the code with
> clever tricks, individual style quirks, unexamined (subconscious) 
> assumptions about inputs and environmental conditions, and the like.
> The code coming out of a good review, or a good-synergy pair, is
> thus of much higher quality and more valuable than the results of a lone
> coding session of even a very good coder.

I couldn't agree more.  I worked for a while with another programmer who
was very good and I know while we were working together it seemed as if the
whole of our efforts exceeded the sum of the parts.  This was very likely
due to the fact that while we both agreed on general principles, our skill
sets and backgrounds in programming were very different, so we tended to
each see things the other did not. 
Additionally, because programming is a pure mental excercise (if you
discount the typing), psychology and morale play a very large role in
productivity for a programmer and having a second like-mind (even if only
to bounce ideas off of) can have a huge positive effect on that aspect.

I much prefer the "continuous ongoing code review" idea better than a
formalized procedure (if I understand what you mean by it correctly). 
Working in pairs provides this as a side-effect rather than having a formal
procedure for code-review and seems less time-consuming overall.

> 
> > Agreed with the "Art" - many programmers give one the impression that
they
> > perceive themselves as a Prima Donna of the software industry :-) Ask
> > someone to look at their code (as in code review) and they look
offended -
> > like you'd just asked for their first born or something :-) A severe
lack
> > of comprehension is the general response - "You want to look at *my*
code?
> > What one earth for! It's perfect (by definition)" :-).
> 
> I fully agree with you.  But that implies my stance in the above
paragraphs,
> not yours:-).  Actually the root of the problem may be in 'my' vs
'yours',
> the "*my*" in your quote being correctly emphasized:-).

Actually, when I say "art", I am using it in the sense of "skill", as in
"martial art" or "art of design" versus the broader sense that includes
unrestrained personal interpretation.  In this sense "art" means taking
basic, established techniques and internalizing them to the point where
they are second-nature. At that point, personal expression becomes an
extension of those techniques - not a deviation from them.  My experience
has been that programmers at this level feel a sense of pride and personal
accomplishment and _appreciate_ code review (otherwise, who will ever see
and appreciate their accomplishment?).  I suspect this to be a major
driving force behind open-source software - it's the equivalent of a public
demonstration of one's skills. 

This is not to say that radical departures can never be beneficial, but
these departures are rare and do require intense peer review.  

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308

"Then with your new power you'll accomplish all sorts of cool stuff 
 in no time, and We'll All Be Sorry.  At that point you can either 
 gloat a bit, and then relent, or go ahead and send the robot army 
 after us." - Quinn Dunkan