Peer Review
Being able to read others’ code. In fact, you rarely get to write a software system from scratch; most of your time will be spent maintaining and extending existing code.
Being able to give feedback on others’ work. This is a common practice called peer review.
To give you a feel for this, while accommodating the time constraints of the semester, we will have you review problems that are familiar but programs that might not be. That is, you will review your classmates’ solutions as well as receive feedback on your own. You will do this anonymously, but remember: Professionalism!
We will use a system called Peerceptiv to conduct peer review. We will provide details on how to access Peerceptiv on EdStem. Peerceptiv will also include a rubric that you should use to provide feedback.
The following text is freely adapted from notes by Prof. Joe Politz, who did his PhD at Brown on peer-review.
Things you liked about the code.
Any parts of code you don’t fully understand.
Suggestions for improving the code. Indicate whether these are meant to improve correctness, readability, performance, etc.
In all of this communication, remember to be polite and professional. Focus on giving crisp feedback (length alone is not a virtue: the length should be proportional to the amount of content) and writing clearly. A huge part of the job of a working software professional or researcher is accurately communicating about code and system behavior, and doing so in a way that is about the system and not about any specific person.
Some tricks for this: avoid statements that reference the author of the code, frame negative feedback as possible improvements or ways your expectations were violated, and take responsibility as the reviewer for anything you don’t understand. You can see some examples in Politz’s notes (search for “Examples”).
Finally, here’s how industrial programmers judge during code reviews.