How can we motivate students to review each other's code?

Question

Code review is crucial to student's academic and professional lives, yet some students see code review as a burden and a new way teachers have found to "ditch some work".

By experience, code review works better if the majority of the class is into it, yet this is becoming more and more rare.

What strategies do you have to motivate students to review each other?

Sidenote 1: I've seen some teachers ask the class to write some code and ask a student to showcase and the rest of the class would review it, it did not work very well, because it was always the same 4/5 students participating.

Sidenote 2: I'm dealing with high school and college students

Answer 1

You have an opportunity for several things here:

1. You can make it a small-team effort rather than a whole-class thing. Say, a team of about 5.

2. The team reviews everyone's code in sequence so all get to participate. Instead of a "code-review" it can be a "code-quality-workshop".

3. The team has to write up the results of the review, with an addendum by the code's author about how the code was improved. (Writing is good.)

4. A whole-class retrospective on the process and its effect. (Retrospectives are good.)

If you have several groups working at once, you will need to wander around and participate in each group, giving pointers on process (rather than product). But you also need to do that if you have the whole class as the set of reviewers, of course.

---

An alternative to code reviews, of course, is pair programming, where the need for reviews is lessened or eliminated. Two minds working together are stronger than than the two working separately it turns out when creating code. Code quality has been observed to improve and quantity (statistically speaking) doesn't go down by enough to overcome the quality issue.

---

You may need to add a level of peer evaluation/review to this as well. Something like the following has worked for me over several years. In any group assignment, each member of the group also submits a peer review sheet. For a group of two (e.g. pair programming) I ask each participant to detail the most important contribution of their partner AND their own most important contribution. I don't ask who worked harder or ask them to make an evaluation. I ask them for the contributions.

In a group of about five, I will ask each member to name the (say) three most important members of their group and to mention the key contribution of each. I tell them that they can include themself in the list of three. I also ask, separately for their own most important contribution.

I let them know at the beginning of the course that this will happen and its parameters, so it isn't a surprise.

Students see that they are supposed to contribute to a group and are not asked to speak ill of anyone. Keep the questions entirely positive. But you also learn a lot from what is not said and who is not included in the contributor list.

If the project happens outside your view, you also learn things about individuals that you can not otherwise know. I've had students I thought were slacking who were praised by teammates for making the team work properly.

These peer evaluations are not optional.

This same idea was also discussed here: https://cseducators.stackexchange.com/a/2578/1293

---

Let me note that there may be cultural limitations here. In some cultures it may be odd to name oneself as a top contributor. In others it might be very natural. You can modify the scheme, of course, either requiring or forbidding naming oneself as one of the top people. Use your judgement here.

Answer 2

Some ideas:

1. Show them that you're serious: grade the student's code reviews -- initially based on effort, then later based on correctness.

   This will definitely be a lot more work for you, but it does make sure that everybody is practicing and kills accusations that you're trying to avoid work. You may want to deliberately invent poor and buggy code samples to give to students if you're going to take this route (as opposed to having them grade each other's work). You should probably do this carefully to avoid overloading both you and your students.

2. Incentivize code reviewing somehow.

   For example, one idea is to offer students the opportunity to code review each other's work before they submit it -- you then proceed to grade their code fairly harshly. Students are then incentivized to take code reviewing seriously because it's a way to help mutually ensure they get a higher grade. (After all, in humanities classes, you proofread each other's essays -- why not proofread each other's code as well?)

   Another idea is to tie it into regrades: if students want a regrade of a past assignment, they also need to conduct code reviews related to that assignment (and probably a retrospective). However, this would probably only really feel worth it if your assignments were on the harder end of the scale/you grade strictly.

3. Set up situations to make code reviewing happen organically.

   For example, give group projects/pair projects. Tell them that you'll be grading them not only on correctness, but based on how sound their project's design is/how well they follow your in-class style guide. Students will then naturally be incentivized to at least check their partner's work.

4. Incorporate code reviews into your exams.

   Give them short, invented code samples, and ask them to identify all of the style and correctness errors they can find.

Answer 3

Have you considered something like a Refactoring Kata?

A Refactoring Kata is a project that works exactly as described and passes a given set of unit tests, but is written for the express purpose of being abysmal code.

Giving the students horrible code written by someone other than their peers could help people who may think they are being "mean"/not wanting to make another student feel bad. Taking away that human element and splitting it up into a group project may motivate more students to participate more actively and learn how to be critical without "pulling punches" per se. Students could also compare how their peers solved problems differently than themselves.

I did this at a job rather than in an academic setting, but I think it definitely could have applications. This was a refactoring kata we did specifically to teach the team the strategy design pattern. It is one of the most popular Katas, GildedRose.

https://github.com/emilybache/GildedRose-Refactoring-Kata

It is a good way to see what Katas are all about, and gives a good example structure for creating your own Katas. I see something similar was suggested in another answer, and I concur that creating a Kata that fits your curriculum is most likely the way to go here if you have the time and resources.

Answer 4

some students see code review as a burden and a new way teachers have found to "ditch some work"

There's an easy way to teach them to do code review without thinking that you're ditching work: ask them to review some code which you wrote for the express purpose (or, if you have some suitable code from the previous year's homework, use that). This can be set as homework. For what it's worth, I have had to identify errors in code printouts both in exams and in job interviews, so this isn't an original idea.

Answer 5

Why not create a multi stage project for them?

They all code up something for stage 1. You then give out each students stage 1 to another student and ask them to complete stage 2 using the code that they received.

Next the completed stage 1 and 2 work is given to another student to complete a stage 3 (they are then reviewing, extending and understanding another 2 students work). This will help them learn to work with other students code and they are learning from each other. An example of such a project may be a multi page form, submission and validation.

Answer 6

Providing the class with pre-chosen code, for the specific purpose of teaching quality control skills and methods (of which review is a component) will help to ensure the code is suitable for teaching the points required, and does actually contain review points where you can provide notes and grades fairly.

Asking students to peer review may mean some get easier or harder code to review than others, and some get code poorly suited to review lessons.

Teaching the class the importance and focus on QC and quality production methods, puts review in a context - they will need this knowledge professionally as almost all software businesses do operate some form of QC and/or review. Simple as that.

By giving them code you have chosen, you can be sure that whether individually or in groups, they have a target number of important and secondary review points to identify, which may motivate them to look harder. The rationale is, if you have to find and review 10 major points in a block of code, as part of a review, you might spent extra time taxing yourself to find the last 3 items, compared to an open-ended count. You'll probably remember them better as well.

Answer 7

I think you've nailed the issue: some students will think that code reviews are just a way for the teacher to "ditch some work". You need to show them that code reviews are actually a best practice in the industry. After all, they are studying for the life, not for the school, right?

I'd call in a guest lecturer. You probably know people who have worked in the non-academic world for quite some time. Ask around your friends and other contacts: I would assume most people would be honoured if they were asked to give a guest lecture. Also if they can't make it, maybe they can recommend someone else.

The person absolutely doesn't need to be from any "fancy" company like Google or Apple, I think any local software shop will do provided that the guest has a credible enough (for the students!) CV, say, more than five years of practical experience.

The students will find the lecture a refreshing break from the usual routines and will hear the facts from a third party who has no incentive on ditching any work anywhere.

---

Finally, I thought about another method too: give them a homework assignment to do some actual code review in codereview.stackexchange.com! Let them pick the piece of code to review themselves (or pre- select a few nice tasks from which they can choose).

It'd be great if they could post their reviews to the actual site, but you could also use your school's intranet or something. If you go with the actual site, consider whether you want to create everyone some random accounts just for the course or if you'd rather encourage them to create their own personal Stack Exchange accounts.

Either way, they get to review some actual code, and it's not from anyone that they know, so they don't need to hold back.

Answer 8

Set a formative peer-reviewed assignment using an LMS.

This is based mainly on part of an answer I suggested to a different but related question here.

Coding mini-assignment- peer grading on Moodle

Given that photocopying code is a non-runner, and distributing files can be difficult, I set up a peer-graded Assignment on Moodle. Each learner had to work on a mini-programming assignment and had two days to complete it and submit online.

This assignment was of a very similar structure and marking scheme as an upcoming summative assignment.

Firstly, getting this to work the first time on Moodle was very time consuming. Even on the day, there were several delays in getting started.

The grading rubric identified many elements such as use of "appropriate" names for variables and functions, header info, docstrings (Python), clear user prompts/instructions, working code, use of comments and so on.

When peer-grading, it is possible to place a comment in each section to explain why mark(s) were lost, and each marker can place a final comment/general observations.

Benefits of Moodle Peer assessment

Learners are assigned the work of others to mark randomly

Anonymity is an option in the setup

Each learner was forced to really look at the grading scheme, which was provided from the outset. Many lost marks for simple things that they should have included (e.g. header information). This is important- that they realise they can get some marks even if the code doesn't work completely or partially.

All got to see examples of other learners approaches, structure, working and non-working code. Seeing mistakes others make should help them identify those that they make themselves.

Teacher can review all more easily without looking through a lot of paper, i.e. the grades given and received by each learner, and the comments given and received.

Difficulties

I have to say, from a practical perspective, it ran about as smooth as a dragons tail (i.e. not at all smoothly) but this was likely due to my inexperience with using this in Moodle. That said, it was better than paper.

Some students failed to provide any feedback even when it was a requirement of the exercise.

Answer 9

Make the review actually useful: have them swap their code. When they'll realize that their future tasks depend on their colleague's performance (which is how job works), they'll appreciate the need to keep each other in line.

Example:

1. exercise 1: write code doing X.
2. code review
3. swap code with another student.
4. exercise 2: expand given code to do Y.

This will more closely resemble how actual team works.