A Reviewing Trick I Learned A Long Time Ago
I learned this way of reviewing artifacts from Cal Caldwell, a friend of mine from my instructor days. The technique is for doing code reviews, but I’m going to be using it later this week for some design docs. Anybody who recognizes this technique can chime in with what it’s called:
-
Every reviewer gets a different “hat,” i.e. a POV that they adopt when reviewing, e.g. looking for coding guidelines, looking for readability, looking at a feature from an architecture pov, looking at it from a particular customer pov, etc. Anyone can have feedback on anything, but the idea is that with different folks wearing different hats, you get a greater coverage.
-
Every reviewer brings review comments to the meeting, i.e. you reviewer before hand and only report at the meeting.
-
Every reviewer must start with something nice! Too often, engineers focus on the negative. Saying nice cushions the blow and reinforces the good things so that they don’t get cut.
-
Each piece of feedback will be logged (hopefully by the person that provides it) and spoken to the reviewee, but will not be argued with. If a reviewee disagrees, they keep it to themselves, asking only clarification questions to make sure that they understand the feedback. What feedback is applied it up to the reviewee and any follow up arguments happen offline.
That’s it. The best code reviews I’ve every participated in used this technique and I can recommend it highly for that. On Monday, we’re going to use it to get through a large number of design docs, so I’ll let you know how that goes.