The University of Arizona
banner image

CSC 453: Compilers & Systems Software

Peer Reviews

Form to provide github ID. You won't be able to view the code you need to review unless we have your github ID.

PA1 Peer Reviews, Due Thursday September 15th, 11:59pm. Typical 24 hour late period applies.

PA2 Peer Reviews, Due Thursday September 29th, 11:59pm. Typical 24 hour late period applies.

PA3 Peer Reviews, Due Monday October 24th, 11:59pm. Typical 24 hour late period applies.

Motivation for Peer Feedback

Because of the pattern matching in Haskell and its functional nature, it is possible to implement a compiler in many fewer lines of code than a compiler implemented in Java. However, it is possible to make any program overly complicated. By reviewing other students’ code and your own from the previous assignment, we hypothesis that students will learn many more coding patterns and work toward simplifying their own code design. The main beneficiary of this should be the students’ future selves who are building on previous programming assignments. More generally, learning how to read other people’s code and provide constructive feedback are important life-long, career skills.

Logistics of Peer Feedback

The peer review process is the following:
  1. Programming assignment source code will be posted for class: After each programming assignment due date, the graded assignments will be placed in a private github repository that everyone in the class can see. We will be aiming to post the codes 24 to 26 hours after the assignment deadline. Each submission will be put in a directory, where the directory name will be based on codes selected by the student or students who submited the code: compiler1234/, compiler4242/, etc. The README from the assignment and revision control log will be removed to ensure anonymity. DO NOT put your name or other identifying information in your source files. DO NOT share your group's compiler ID. The results of the grading script will also be put in the directory so that anyone reviewing the code can see how the compiler performed on the various test cases.
  2. Each student will be randomly assigned two other submissions to review.
  3. Each student will fill out and submit the peer review google form for the appropriate assignment (see https://goo.gl/forms/MBw8rGtIS41sX2l72 for the PA1 review form).

Frequently Asked Questions (FAQ)

(Q1) But what if someone reads my code, copies it, and then builds on it for the next assignment?
(A1) Kudos to you!! That means you wrote code that was clear to understand. You could record this occurrence in your online portfolio so employers see that you have exhibited one of the most important skills in computer science, communicating what you have done effectively to others. Also, we will expect students to indicate in their README if they built off of another assignment. Recall that the student(s) will still have to add to the code for the next assignment, and in the end the programming assignments are a tool for learning and do not count much for the overall course grade. In reality, I expect this to happen quite rarely, but if it does please let me know so I can privately congratulate you as well. Such an occurrence would make great fodder for a strong reference letter.
(Q2) If I am working with a group on the programming assignments, can we do the reviews together?
(A2) Even if you are working with a group, each individual student is responsible for doing and submitting their own peer reviews. You can collaborate with anyone while doing the reviews, but use your own words and do not paraphrase anyone else. It is amazingly easy to detect copying in reviews. Paraphrasing is also pretty easy to see. Copying or paraphrasing someone else's peer review sentences will be treated as a violation of the university academic honesty policy. If you have someone do the reviews for you (as well as their own if they are in the class), we MAY not be able to detect it, but you will not learn as much. Forcing someone else to do your reviews for you would be a serious breach of the code of conduct and will not be tolerated.
(Q3) How long should this take?
(A3) The peer review process is a new addition to this class. Please provide me feedback as to how long this is taking. I will also probably have some polls on Piazza. I recommend that you skim through all the code in about 5 minutes, and then spend 10 more minutes studying that part of the code in more depth and answer some questions about it. In other words, my hope is that this will take 15 minutes per review. Each peer review assignment involves 2 peer reviews and one self review. If it is taking more than 2 hours to do an entire peer review assignment, please come see me in office hours ASAP.
(Q4) Do we get to see the peer reviews of our code?
(A4) Yes, everyone will see all of the peer reviews for all of the submissions. They will all be posted after the peer reviews have been graded.
(Q5) What if someone says something unprofessional in their review?
(A5) We will attempt to address this as we grade. Negative points will be assigned to reviews that are clearly inappropriate. Other reviews that could be construed as unprofessional, but are borderline, will be pointed out in comments on piazza to give people examples of what NOT to do. We will also be providing examples of constructive peer review comments.
(Q6) Will the peer reviews of my submission affect my grade?
(A6) No. This is NOT peer grading. The programming assignments will be graded using the criteria specified in each programming assignment writeup. The peer reviews can just be used as extra feedback you can use to improve the understanding (and possibly the correctness) of your code.