Why Developers Don't Do Code Reviews

Further to thoughts on student-oriented software process, there’s this list from Jason Cohen at SmartBear Software of reasons why developers don’t do code reviews:

• Egos. Don't want other people telling you how to do things.
• Egos. Think it's a waste of time because you think you write awesome code and you're smarter than all the other developers anyway so how could they teach you anything.
• Big Brother. Scary to think of your boss counting how many defects you have. Will that come up in a performance report?
• Time. Besides the "waste of time," even if you think it's not a "waste" it's still a lot of time. Time reading code instead of writing code, which could be considered less fun if you're not accustomed to it.
• Busywork. Without a supporting tool, "review" often means meetings (yuk!), having to gather files together and mark them up, sending files around, parsing Excel spreadsheets full of things like "on line 142 of file //depot/foo/bar/baz.java…", tracking comments, computing metrics, and making reports. All stuff that is boring and not creative.

Some of these things (e.g., busywork) can be addressed by tools (like SmartBear’s Code Collaborator), but most are social issues.

What other reasons can you think of? And realistically, how many of them can be addressed in undergraduate education?