 It is all too
easy to become emotionally invested in the code you've been creating. A
formal group review process creates a stressful situation and fosters
emotional reactions for both the developer and the reviewer.
There
is just no good way for several people to examine someone's code and
suggest changes without it seeming like personal criticism. There is a
feeling of being attacked from all sides and it isn't always clear what
changes need to be made to satisfy the reviewers once the review is
complete.
I
recently witnessed a developer feeling personally persecuted by the
review process. I was part of the review team and the code was from an
inexperienced developer. After only two reviews, this developer asked
management to be excused from any more reviews.
We
reassured her that it was not a personal attack, but her enthusiasm for
the project was gone. She felt completely demoralized. We all wanted to
help, but no one was available to sit with her and guide her. I dreaded
the reviews almost as much as she did because I could feel stress
levels rising, and knew |
time was being wasted.
Pair programming changes
the environment from criticism and competition to learning and
cooperation. Programming partners must explain to each other what they
are doing; one teaches and one learns, then the roles reverse. The
learner is encouraged to participate with new ideas or new twists on
old ideas, gaining confidence all the while.
There
is a discussion between two developers instead of a short lecture from
a superior. There are no criticisms thinly veiled as suggestions, but
mutual discovery and agreement. The resulting code is always better
because it has to pass two pairs of eyes. You end the day with a
feeling of accomplishment instead of animosity.
 |
