Code Feedback Beginners Actually Use and Remember

A student hands you a 40 line Python script that works, sort of, and you can see nine things wrong with it. Point out all nine and you will probably never see their code again. Point out none and they keep the same habits for months. Giving code feedback beginners actually use is about choosing one or two of those nine and saying them in a way that makes the next script better.

I have run club sessions for teenagers and evening classes for adults, and the feedback that sticks looks surprisingly similar for both groups. It is short, specific, tied to something the learner was trying to do, and it leaves them with a next step they can try in ten minutes.

Why Most Code Feedback Gets Ignored

Experienced programmers review code the way they were reviewed at work: a list of comments, line by line, covering everything from naming to structure. For a beginner that list reads as a verdict. Research on novice learners and plenty of classroom experience point the same way: after the third or fourth correction, people stop reading and start feeling.

The other problem is vocabulary. "This should be a function" means nothing to someone who wrote their first function last week. "You typed the same four lines in three places, what would happen if you needed to change the greeting?" lets them discover the reason themselves.

Timing is the third trap. Feedback given while a learner is still fighting a bug feels like an interruption, and feedback given after they have moved on to a new project feels like homework from the past. The window that works is right after the program runs for the first time, when they are pleased and curious about what could be better.

Pick One Thing, Sometimes Two

Before you write anything, sort what you see into three piles:

Breaks the program: bugs, wrong output, crashes on certain inputs
Blocks the next lesson: habits that will hurt soon, like giant scripts with no functions
Style and polish: naming, spacing, clever shortcuts

Comment on the first pile, then at most one item from the second. Leave the third pile alone for now unless the learner asks. A variable called x2 is not worth a comment in week three. It becomes worth a comment once they are writing programs long enough to get lost in.

A quick example from last term: a 13 year old built a quiz game with every question in its own if block, a crash when the player pressed enter without typing, and inconsistent capitalisation in the prompts. We talked only about the crash. Two weeks later she moved the questions into a list on her own, because adding the twentieth question by hand had become annoying.

A Simple Shape for Each Comment

Every piece of feedback I give follows the same three parts, and new volunteers at our club pick it up within a session:

What works: one honest sentence about something specific, not "great job"
One question or observation: "What happens if someone types their age as a word?"
A small next step: "Try wrapping the input in a check and run it with the word ten."

The question format matters. When learners find the problem by running their own code, they remember it. When you tell them, they remember that you were right. That same idea drives our approach to helping a beginner debug without fixing the bug for them, and feedback is really debugging done after the fact.

The Advice I Stopped Following

The feedback sandwich, praise then criticism then praise, is standard teacher training. With code it backfires. Learners quickly learn to skip the bread and hunt for the filling, and the generic praise starts to feel fake. Worse, the closing compliment makes the actual point feel optional.

What works better is honest, specific praise only when it is earned, and a clear single point. "Your loop stops at the right place, which is the part most people get wrong" is worth more than three rounds of "nice work." If the code genuinely has nothing to praise yet, say what the learner did well in the process: they asked early, they tested an edge case, they read the error message.

Written, Spoken or Side by Side

The format of feedback changes what a beginner takes away.

Format	Works best for	Main risk
Spoken, at the screen	Bugs and logic problems	Learner forgets it by next week
Short written note	Habits and structure	Tone reads harsher than intended
Comments in the code	Pointing at an exact line	Turns into a long red list

My default in club sessions is to talk through one point at the screen, then leave a single written line in their file, such as "next time: try splitting the menu into its own function." It gives them something to look at when they open the project again a week later.

Turning Feedback Into the Next Exercise

The best feedback ends with something to type. If a learner repeated code, the next exercise is to refactor one repeated block into a function, which is a natural moment to share why your first functions should do only one thing. If they never tested odd inputs, the next exercise is to break their own program in three ways and fix one.

Keep a small notebook or spreadsheet with each learner's one current focus. In a club of 15, that list is the difference between remembering that Maya is working on naming and repeating the same advice to everyone. When the focus is clearly fixed in two or three projects in a row, pick the next item from the pile.

FAQ

How quickly should beginners get feedback on their code?

Within the same session if possible, or within two or three days at most. Feedback on a project they finished three weeks ago lands on code they no longer remember writing.

Should I rewrite their code to show the better version?

Rarely. A rewrite shows that you can code, not how they can get there. Show a two or three line example of one idea, then let them apply it to their own program.

What if a learner keeps making the same mistake?

That usually means the concept is missing, not the effort. Stop commenting on it and teach it again with a tiny standalone example, then return to their project.

The Practical Takeaway

For your next round of feedback, sort what you see into breaks, blocks and polish, comment on one or two points only, phrase the main one as a question, and finish with a ten minute next step. Track each learner's single focus and change it only when it sticks. More ideas for running sessions are in our teaching code section.