One of the problems I have with code reviews, over and above the fact that after-the-fact review is a waterfall phase that introduces delays and rework into the feedback loop, is that there's usually an implicit power imbalance—a hierarchy. 1/6

Shouldn't be that way—I'd prefer two equals just looking for things that the other missed, but it often is. The person doing the review is the powerful person, the reviewee (not just the work, but the person, too) is being judged by that powerful person. It's bad all around. 2/6

If that situation exists because of a skills imbalance, the time is best spent teaching, using the code in front of us as an example, than simply correcting stuff. 3/6

Of course, it would be better still if the more-skilled reviewer were collaborating with the other person as the code was being written. Teaching and coding can go on at the same time and no after-the-fact inspection is required. 4/6

Because of that, my real preference is to eliminate code review entirely by working collaboratively in an ensemble/mob (or a pair as a second choice). Identify problems _as_ they're being created and teach each other how to not create those problems to begin with. 5/6

After-the-fact inspection isn't nearly as good. 6/6