▼Fall 2024:
Accelerated Introduction to Computer Science
    contents    up   

Peer Review🔗

Two important skills you need to grow as a programmer are:

  • 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.

You will find you need these skills in all kinds of contexts: industrial, open source, scientific, etc.

We cannot simulate all the conditions you will face later, but we’re going to make a start giving you this experience. Instead of reading arbitrary programs, you will read the solutions your classmates produced to some of the homework problems, and you will give them feedback on how they did. In turn, you will receive feedback from others on how you did.

Please remember to write your feedback anonymously. However, anonymity is not meant to provide a shield for incivility. We will be reading your work, and in addition students can flag work. Be professional: Diversity and Professionalism!

We will use a system called Peerceptiv to conduct peer review. More details about how to access Peerceptiv will be provided on EdStem. Peerceptiv will also include a rubric 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.

At a high level, here is what we want you to do. Read the code, which represents an alternate solution to the same problem that you worked on. Provide feedback about:

  • 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.

    contents    up