Why I advocate blind code reviews



A blind code review is when someone asks you to review their code and gives you a diff and possibly a link or quick explanation of why the change was required. Rather than sit down with them to review the code together, you spend 20 minutes or however long it takes to read on your own first before inviting them over.

If a developer has several commits needing code review and perhaps some of them undo, rework or cleanup a previous commit, decent VCS software like git allows you to generate diffs against a range of commits or you could diff the merge branch against the story branch.

Then of course you review the diff and make your notes and feedback. When reading the diffs make sure open the file to get an idea of context. Was the code added inside the appropriate try {} catch blocks? Does it fit in with the classes existing API?

Make a list of notes, list any questions or things that confused you. Ask yourself what the alternative and better approach is. Then invite the developer to join you after twenty minutes to answer the questions, explain your ideas and why they're better. If something can't be improved, can a comment be added to the place that caused you to ask that question?

Don't allow yourself to be lead through a code review with someone saying "I did this, so then I had to do that". If someone says "start reading from here first" it's a bad sign, which I why I think blind code reviews work much better. You get a _real_ sense of if code is confusing. You get almost the same impression as would the person who stumbled across it later for maintenance.