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