Reviewing code is something you learn to do by actually doing it. Over time, as you get more experienced with the code base, you'll become familiar with various patterns, anti-patterns, and habits, and be able to spot them in a patch, and comment on them - and pointing them out when they should be changed.

During the sprint, we will hopefully get an opportunity to do a live code review, and show you what goes through our heads when we review code. Regardless, here are some tips for reviewing code:

1. Remember, critique the code, not the coder. While programming is egoless in the perfect world, it's not a perfect world, and these are people's inventions and creations on display. Be sensitive with your language.
2. You don't just have to find problems. It's perfectly legitimate to find a part of a change you don't understand, and ask what it means, or what it's for. This is how you learn! And it might indicate a legitimate problem with the code (such as a lack of appropriate comments or unclear code). Don't be afraid to ask questions.
3. Look for the things that a piece of code might not be considering. What are the tricky edge cases that might cause a piece of code to break?
4. Is there a more Python-ic, jQuery-ish or Backbone-y way of doing things?
5. Examine the style of the surrounding code. Are the changes adhering to that style?
6. Look at the logic of what the changes in the code are doing. Is there a more efficient way of doing it?
7. Don't open issues on code that the reviewee didn't change, even if you notice it in the background. Instead, file a new issue or open a new review request to fix that problem separately. An exception to this would be if their code changes necessitate other changes in existing code (for example, if they rename a variable but miss some usages of it).