An aggressive checker is one reason for the author to resort to defensiveness. The way the negative feedback is delivered is important. An enthusiastic checker might not be aggressive but the author might still feel that "he is out to get me" and defend himself by rejecting the findings he perceives hostile. Again, the value of code inspection declines with each rejected valid finding.

Some checkers really are out to get the author. Finding a mistake or a hole in logic makes their day. They cannot help but appear belligerent as they reveal their findings and revel in the power of judgment. Blurting out sentences like "You're making stupid mistakes!" or "I would have written this much better", is an act of war. The author might take care of the findings this time, but he'll very likely start planning revenge. Antagonistic relationships between checkers and author are rather unhelpful for code inspections.

Chapter 2. "Symptoms" describes the psychological setup of inspection. A checker that attacks practically forces the author to defend, which is bad for the inspection. All participants should look at the code as an artifact, as a real thing, a product of its time. It should be seen as something not linked with the author. The author must be the only one to draw conclusions about improving himself from the mistakes and errors. While checking and giving feedback, it doesn't matter why the product is defective, the reality is that it is. Later it might time to make sure such mistakes don't happen again.