Learning outcomes
- Read, review, and improve others' code
Core concepts
Lessons
Module goal
Understand that professional coding is collaborative, and develop the skills to give and receive feedback on code constructively.
Lesson 1 of 5 · lecture
Why code review exists
Step 1 of 2
Every project so far has been reviewed by exactly one person: you. In professional settings that almost never happens — code gets read, questioned and checked by others before it becomes part of a real product. This isn't distrust; a second set of eyes reliably catches what the original author can't see, precisely because they wrote it and know what they meant.
The proofreading parallel
A writer reads past their own typos and logic gaps because they already know the intent. Someone encountering the code fresh catches what the author has gone blind to. This happens to everyone, at every level of experience.
Guided labs
Lab — peer review practice
- 1.Review a provided sample script with realistic issues: a function doing too much, a repeated block of logic, an unclear variable name, and no error handling on user input (substitute a real peer's code if one is available)
- 2.Using the structured approach from Lesson 3, write out actual review comments — at least one strength and three improvements, each with specific reasoning and a suggested direction
- 3.Then self-review your own Advanced Capstone (Repair Tracker) with the same lens, using the checklist from Lesson 2
- 4.Add proper docstrings to at least three functions in the Repair Tracker
- 5.Write a short README.md for the project and commit it using Git (Module 13)
Teaching point
Example of the commentary expected — Strength: the database functions are cleanly separated from the menu logic. Improvement 1: add_repair() and update_status() both open and close their own connections; centralising this fully would reduce repetition further. Improvement 2: the variable id shadows a built-in — repair_id (used elsewhere) is clearer and more consistent. Improvement 3: there's no validation on the cost input — non-numeric text would crash the program, which Module 8 taught how to prevent.
Success criteria
You produce genuine, specific written review feedback (not generic praise or complaints), add meaningful docstrings to your own project, and have a clear, informative README committed to your GitHub repository.
Knowledge Check
Question 1 of 6
Why does code review exist, even when the original author is fully capable?
What you read
- What reviewers look for
- How to write clear documentation and comments
What you understand
Key takeaways
- — Professional coding is collaborative
- — Clear communication matters as much as clean code
Hands-on lab
Lab tasks
- 1.Peer-review a partner's (or sample) codebase and leave structured feedback
Knowledge check
- Identify strong vs. weak code review feedback
Write your answers in your own notes before moving on — explaining a concept in your own words is the fastest way to find the gaps.