Chips’nCode
← Back to Education
Education digital-technologies year-9

Review and Improve

A structured review page for testing the program, giving useful feedback, and identifying concrete improvements.

Published Updated Type activity

This stage focuses on review and improvement rather than new syntax. The goal is to make the program clearer, stronger, and easier to maintain.

Project Navigation

Pet Services Program (Feedback)

Lesson 3: Feedback and Improvement

Mini Project: Pet Service Booking System

Project Overview

We will create a Python program that simulates some type of pet grooming service. The program will collect and interpret information from the user to create a booking summary and calculate a cost.

Why we do feedback in programming

In the real world, programmers don’t build software alone. They review each other’s work to:

  • spot bugs and edge cases the original coder missed
  • improve clarity for the user (and the next person reading the code)
  • make the program easier to maintain and improve later
Important: Feedback is about improving the program, not judging the person. Be specific, kind, and useful.

Lesson 3: Learning Intention

  • I can give constructive feedback to one of my peers based on specific criteria.
  • I can recommend areas for improvement based on specific criteria.

👥 Feedback Pairs

Today you will work in a feedback pair (think: “code review partner”).

  • You will be paired with someone at random.
  • You will review each other’s final code (the finished version you are submitting).
  • Both people must upload their .py file and comment on their partner’s work.
Rule: Your feedback must be based on what your partner’s code actually does when you run it. If you don’t run it, you don’t really know.
This week’s seeded pairs
If your assigned partner is sitting at your table, swap with another pair (so both pairs still end up with “not at my table” partners).

Pair 1: Student A + Student B

Pair 2: Student C + Student D

Pair 3: Student E + Student F

Pair 4: Student G + Student H

Pair 5: Student I + Student J

Pair 6: Student K + Student L

Pair 7: Student M + Student N

Pair 8: Student O + Student P

Pair 9: Student Q + Student R

Pair 10: Student S + Student T

Pair 11: Student U + Student V

Pair 12: Student W + Student X

Pair 13: Student Y + Student Z

Pair 14: Student AA + Student AB

🔎 Code Review Criteria (what you MUST check)

Your feedback must include at least one comment from each section below:

1) Inputs and Variables
  • Are all required inputs included?
  • Do variable names make sense?
  • Are numbers converted using int() when needed?
2) Decision Making (if / elif / else)
  • Does the pricing logic make sense?
  • Are service options handled properly?
  • Does it handle unexpected inputs (or at least respond clearly)?
3) Output and User Experience
  • Is the booking summary easy to read?
  • Does it show all key info entered?
  • Is the total cost displayed clearly?
4) Code Quality
  • Is the code readable (spacing, structure)?
  • Are there helpful comments or headings?
  • Could someone else understand it?

✅ What constructive feedback looks like

Good feedback (specific)
  • Your booking summary is clear and includes all inputs. Nice headings.
  • Your service type check works, but if the user types something random, it doesn’t respond. Consider an else message.
  • The price changes based on size, but it’s not explained to the user. You could print a line explaining the rule.
Not helpful feedback (too vague)
  • Looks good.
  • Nice code.
  • This doesn’t work. (No explanation)
Minimum standard: Your partner should be able to make an improvement using your feedback without needing to ask you what you meant.

✅ Peer Code Review Checklist (use this while you review)

☐ I am reviewing someone who is not sitting at my table.

☐ I ran my partner’s program (or carefully traced it) before writing feedback.

☐ I checked that required inputs are included (name, breed, age, size, service).

☐ I checked that numbers that need maths use int().

☐ I checked the pricing logic uses if / elif / else and makes sense.

☐ I checked the booking summary output includes all key information and the total cost.

☐ I gave at least one improvement suggestion from each of the four criteria sections.

☐ My feedback is written in full sentences and is clear enough to act on.

📤 Submit (Discussion Replies Below)

Teacher worked solution: After you’ve had a proper attempt (and you’ve tested your code), compare your program to the teacher’s worked solution to spot what you can improve.
Teacher worked solution 

In the discussion replies below this lesson post, you must do two things:

  1. Upload your final .py code file
  2. Comment on your code review partner’s program using the criteria above
File naming rule:
Save your file as: PetService_FirstnameLastname.py
Example: PetService_AlexNguyen.py
How to upload your .py file in your reply
  1. In Thonny: File → Save as and save your final program.
  2. Go to the discussion replies below and click Reply.
  3. Use the Attach button (paperclip icon) to upload your .py file.
  4. After uploading, write your feedback comment underneath.
Feedback comment template (copy and fill in)

Use this structure:

  • What works well: (1–2 sentences)
  • Improvement suggestion 1: (linked to criteria)
  • Improvement suggestion 2: (linked to criteria)
  • Optional next feature: If you had more time, what would you add?
Reminder: Your comment should reference the program’s behaviour and the criteria. “Looks good” does not count as constructive feedback.