Defending the Python lanuage...

[Peter Milliken]

G'Day Cliff,

"Cliff Wells" <logiplexsoftware at earthlink.net> wrote in message
news:mailman.1012590723.7301.python-list at python.org...
> 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.
>

Not sure what you mean by "continuous ongoing code review". I used to be a
"team leader", I have "looked after" groups of programmers between 1985 and
2000, bitter experience taught me to "review early and often" i.e. diivide
the programmer's work in small units and as each unit is completed review
it - never, ever, ever let the stuff build up to the point where after an
unfavourble review you are faced with the decision to either miss schedule
because it should be re-written or forge ahead regardless and hope that it
will come good through some miracle of extra effort on some ones part :-).
There are so many what I will class as "poor" programmers in the industry,
that this is a necessary technique when you have to "manage" other
programmers. So I assume that "continuous ongoing code review" is similar to
my idea of "early and often"? :-)

<snip>

>
> 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.
>

I think you are correct about the open source motivation etc, but in any
typical project/company I have worked for, it is *relatively* rare to find
people who welcome a review of their code. The people you find in Open
Source stuff are the people who view programming as a "joy" (hobby) rather
than a "job". These people, in my experience, tend to be better programmers
(probably because they really do "care" and have pride in their work? :-)).
But the majority of people I have worked with over the years forget about
programming the minute they step out the corporate doors, it is nothing more
than a job to them - very sad :-). These people tend to be the people who
view their work as "Art" rather than increasing their skills as an "art" :-)
They do no external reading, they are not interested in seeing how other
people have solved similar problems etc etc.

Peter


> 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
>