Giving Feedback Students Use

Most feedback students receive is never used. They look at the score, skim a comment or two, and move on. That is not only the students' fault: comments that arrive late, list every flaw, or say "unclear" without saying what to do give them nothing to act on. Research on feedback is clear that it can help a lot, and also that it often doesn't: in one large review, more than a third of feedback interventions made performance worse. The difference is in what the feedback says and what students are asked to do with it. This page covers how to write comments students will use, on code, proofs and written work, and how to get them to use them.

Defaults that work. If you only take four things from this page:

One to three priorities per submission, not every flaw.
Every critical comment says what to do next, or what to check.
Comment on the work and the process, not the person.
Give students a reason to use it: a revision, a next assignment that builds on it, or a short "what I'll change" note.

What good feedback answers

Hattie and Timperley's review frames useful feedback as answers to three questions:

Where am I going? The goal, usually the rubric criterion or learning outcome.
How am I doing? Where this piece of work stands against that goal.
Where to next? The next step. This is the one most often left out, and the one students can act on.

They also found that feedback works best when it is about the task ("this invariant fails after the swap"), the process ("tracing a small example would have caught this"), or the student's own checking ("how could you test this before submitting?"). Feedback about the person, including praise like "you're so smart," helps least, and can hurt.

Writing comments students can use

Pick one to three priorities. Marking every error buries the important one. If a mistake repeats, mark it once and say it repeats.
Make it actionable. "Rename the three variables in lines 14 to 18 to say what they hold," not "bad naming."
Tie it to the goal. Quote the rubric criterion, so the comment explains the score.
Leave the student some work to do. Point to the region ("there's an off-by-one somewhere in lines 40 to 55") rather than fixing it for them. Good feedback is more work for the student than for you.
Name what worked, specifically, so they can do it again: "Your empty-input test caught a real bug."
Look forward. "On the next project, ..." turns a comment on a closed assignment into one they can use.
Don't compare students. "Below the class average" tells a student nothing about what to do and turns attention to the self.
When the critique is heavy, say why. "I'm pointing these out because the standard here is high and I think you can meet it." Studies of this "wise feedback" found students were much more likely to revise.
Be on time. Feedback that arrives after the next related assignment is due gets ignored. A short comment returned quickly beats a long one returned late.

Weak and better: six examples

Work	Weak	Better
Code	Inefficient. −3	findDuplicates is O(n²) because of the nested loop in lines 22 to 31. With 100,000 inputs that is around 10¹⁰ steps, which is why test 7 times out. What data structure gives you constant-time "have I seen this?" lookups?
Code	Bad naming. Comment your code.	Your test cases are well chosen: the empty and single-element cases caught real bugs. One change for next time: names like x2 and tmp3 make merge() hard to follow. Rename the three in lines 14 to 18 to say what they hold.
Proof	Not rigorous.	The inductive step assumes P(k) but then uses P(k−1) on line 3. Either switch to strong induction or show why P(k) alone is enough. The base case and overall structure are right.
Proof	Wrong. See solutions.	Looking for a counterexample is the right move. The graph you chose has a cycle, which the claim rules out. Can you find a tree with the same property? Try one with four vertices.
Report	Unclear writing. Needs work.	Your results are solid, but a reader has to reach page 4 to learn what you found. Top priority for the revision: put the main finding (the 2.3× speedup) in the first paragraph.
Report	Great job!	Your threats-to-validity section is the strongest part: you named the dataset bias and measured its effect. Keep doing that. Next: Figure 2 has no axis units. Add them before you resubmit.

Feedback on code

Write comments the way a good code reviewer does: point to the line, give the reason, suggest a direction, and say how serious it is. A simple scale helps students decide what to fix first:

Must fix: wrong results, crashes, a requirement missed.
Should fix: design or readability problems that will cause trouble later.
Small: style points worth knowing, not worth points.

Automated feedback tools tend to say what is wrong and rarely what to do about it. That gap is where a person's comment adds the most.

Getting students to use it

The most reliable way to get feedback used is to build its use into the course. These are your instructor's decisions, but worth suggesting:

A revision or resubmission for some or all of the points.
A short reflection before the grade is released: the top comment in their own words, and what they'll do differently next time.
Comments before grades, or comments released separately, so the score doesn't end the reading.
Self-assessment against the rubric before submission, so students learn to judge their own work.
Next assignments that build on the last, with a line in the handout: "Last time many of you ... ; check for it here."

Speaking, not writing

In office hours or section, ask before you tell. "Walk me through what happens when the list is empty" keeps the student doing the thinking, and you learn what they actually understand. Then give one next step, and let them try it while you help someone else.

Doing this at scale

With a hundred submissions you cannot write a paragraph for each. Write the common comments once, as rubric items or a shared comment bank across the grading team, and add one sentence specific to the student where it matters most. That keeps comments consistent between graders and leaves your time for the part that is personal. Grading Faster Without Cutting Corners covers the mechanics.