▼Fall 2026:
Programming Languages
►Peer Review
On this page:
1 Importance of Peer Review
2 What We Will Do
2.1 Uploading
2.2 Reviewing
3 Advice from Others
    contents    up   

CSCI 1730 · Fall 2026

Peer Review🔗

    1 Importance of Peer Review

    2 What We Will Do

      2.1 Uploading

      2.2 Reviewing

    3 Advice from Others

1 Importance of Peer Review🔗

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

  • Being able to read others’ code and other artifacts. In fact, you rarely get to write a software system from scratch; most of your time will be spent maintaining and extending existing code and documents.

  • 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. The ability to read and critique work written by others has become especially important as more and more systems are produced by AI tools.

In addition to helping you prepare for the future, engaging in peer review will also help you see the world through the course staff’s eyes. After all, whenever you turn in a homework, we have to read and make sense of your solutions. If you find someone else’s work difficult to read, most likely so did a course staff member.One of the hidden benefits of being a TA is that you get good at reading! We hope that by struggling to read others’ solutions, you will internalize some lessons about how to make your own work readable. You will realize, for instance, that the “style” guides aren’t there to make your life difficult, but rather to make your work legible. It’ll become clear the first time you read someone who didn’t follow them!

2 What We Will Do🔗

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.

We will use a system built into Canvas. The details will be given to you at the appropriate time. Each peer-review activity will have its own deadlines, which you should check in the system.

All deadlines are firm: there are no extensions. If you think about how the peer-review system might work, you’ll see why this must be the case.

2.1 Uploading🔗

You must upload your work before the starting time on the Assignments page. Please make sure:

  1. The work is anonymized. It should have been already, but double-check and, if it hasn’t been, make sure it is now.

  2. You upload in one of two formats supported by the system. We will give you more information on this per assignment.

  3. You’re uploading the correct assignment! It isn’t necessarily the most recent assignment. We carefully choose which assignments to PR, so please double-check.

2.2 Reviewing🔗

Once you upload, your work will be sent to about three other students to read and review. In turn you will get about three other students’ work to review.

You have the time listed on Assignments in which to write a review. We have provided you with a rubric for reviewing. For most of you this is an entirely new skill, so think of it less as “getting the right answer” and more as a learning experience.

Please follow these rules for your reviews:

  1. Always be professional. Zero tolerance for anything that is not.

  2. Don’t be perfunctory. Take some time to do a good job. Others are doing the same for you.

  3. Don’t use AI to write the reviews. We can tell. (For instance, you actually did the same problem, so your responses will sound quite different from AI’s responses.)

  4. Do not be verbose! Write just what needs to be said. It is rare to need more than 1–3 paragraphs, unless you have very specific things to point out (in which case feel free to write more). You will not be rewarded for verbosity; you will be penalized for it if we feel it’s not contributing value.

3 Advice from Others🔗

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 work, which represents an alternate solution to the same problem that you worked on. Provide feedback about:

  • Things you liked about the work.

  • Any parts of work you don’t fully understand.

  • Suggestions for improving the work. 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 work, 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