They should have read the code and have their comments and questions in order before they showed up for the meeting.
NXT
2010-01-24 04:00:09
+1
A:
This is a good and almost obvious point, but sometimes this is not realistic, sometimes counter-productive (IMO). Perfect planning is nt always available. We have a policy of code read FOR EVERY check-in, whether before or after. I kind of like it.
Hamish Grubijan
2010-01-24 04:08:06
You might also consider not having code review meetings, and using "lightweight tool assisted reviews" instead of more formal inspections. Tools like Crucible or Review-Board take most of the pain and hassle out of code reviews and almost eliminate the need for review meetings.
Sam Post
2010-01-24 04:17:54
I'd add to this that the first step when you meet be to *have the reviewer explain the code to the author*. The author then has a sense of the level of clarity achieved.
Jay
2010-01-24 04:21:27
+2
A:
How about you help the reviewer a bit by fixing your code first; and by pointing out what could not be made clearer and why. He can deal with the rest by himself, and ask for clarifications (which you should mark and remember to fix up later) if he needs them.
Code is by humans and for humans. Don't you both forget that.
So do talk about code. As much as possible and whenever you can, build up the collective vocabulary.
There's my take.
godDLL
2010-01-24 04:08:43
+2
A:
My old answer doesn't really apply now, so let me give a somewhat completely different answer:
Before you present your code, do you have an idea of how to present it? For a bug fix situation, can you show the bug and that it is fixed by your changes? Can you structure things to try to be helpful?
At the code read, study the other person's body language and try to empathize with whatever questions or concerns they have with your code. This may be hard to do at first but with practice it may get easier. Part of this is to understand that unless you are reading someone else's code, the person doing the reading should be in control of how the read is going.
After the code read, you may want to see if you can get feedback about how it went and what that person would like to see to improve the process. This can get complicated if you have to build different styles for each person, but I do think this is what an optimal solution would look like as Fred may want a style totally different than Frank or Ted.
JB King
2010-01-24 04:10:44
Also, don't meet 1:1 until the reviewer has actually read the code in question and actually has comments/quesrions to dicuss
Sam Post
2010-01-24 04:29:43
@sam: I disagree, if they want to read it first before talking to you fine. But it can be good to be there to answer questions. Just don't talk when they are trying to read.
John Knoeller
2010-01-24 04:35:22