You have written Python, documented it so someone else can follow it, and analysed code that was not your own. Today you put all of that together.
You will plan, build, document and test a small Python program that solves a problem you choose. Then you will watch someone who did not build it try it out, and use what you see to improve it.
Keep this tight. Name the bar for the lesson in one breath: a working, commented Python program, tested by someone else, with one improvement made from that test. Students already know the tools; the challenge is choosing a small enough problem and finishing it.
If anyone has no Python environment open, get them into the class editor before the set-up ends so the build starts on time.
Pick a small problem a short Python program could help with. Keep the scope small enough to finish today: a short program that works and is tested beats a big idea that never runs.
Stuck for an idea? Try one of these, or invent your own:
- a GAA score helper that works out the total from goals and points
- a packing advisor that suggests a jacket or raincoat from a temperature and a yes/no rain answer
- a short quiz on a subject you care about, with a running score
- a fixtures or shopping list you can add to, show, and search
- a tip splitter that divides a bill in euros between a group
Your finished build must:
- solve one clear problem with input, a decision or a list
- use clear names and comments, and run without crashing on normal use
- be tried by someone who did not build it, then include one change from what you saw
Before you code, write a short plan (pseudo-code or a quick flow chart). Note one data or fairness question your program raises. Example: for a GAA scorer, should a player's name be stored with their score?
Scope is the main risk. Circulate during idea choice and push anyone with a multi-screen app back to one clear job. A single input-process-output loop with a decision or a list is enough.
Have students jot the plan and the one-line ethics note on paper or in a comment block at the top of the file before they start coding. Thirty seconds on ethics is enough: name the issue, say who it affects, move on. Programs that store names, scores or opinions are the ones to probe. The GAA scorer example in the student text is a model of the length you want.
If a student cannot choose, assign the packing advisor or the tip splitter so they are building within a minute.
Before they open the editor, ask one quick predict beat against their plan: "If the user types this awkward value first, what do you expect your program to do?" They answer from the plan, not from running code. That sets up the self-test they will do later.
Start here. Open a new Python file and build from your plan. Hit Must before the freeze. That alone is enough to go to the swap.
Must (hit these before the freeze):
- the program runs end to end on the normal path
- a top comment names what it does and any ethical or legal note
- your plan is still visible (on paper or in that top comment)
How to get there:
- Put a short comment at the top: what the program does, and any ethical or legal note you spotted.
- Code the core path first so it runs end to end on normal, expected inputs.
- Add clear names for variables and any functions. Comment the parts that would confuse a classmate.
- Test it yourself. If something breaks, use the debugging routine: read the error, find the line, form a hypothesis, test it.
- When your teacher calls freeze on new features, stop adding features and polish what you have so a stranger could try it without you talking them through it.
Need a start? Write each line below as a comment in your file, then fill the code under it.
- Ask the user for one input (a number, a word, or a yes/no answer).
- If a condition is true, do one thing; else do another. Or put values in a list and show or search the list.
- Print a clear result in a full sentence.
After the freeze (only if Must already runs):
- clear names and comments on the main steps
- you have tried at least one awkward or empty input yourself
This is the bulk of the lesson. Resist whole-class interruptions. Circulate with three look-fors:
- Is the program actually running, or are they still designing on paper?
- Are names and comments present, or only working code?
- Have they tried an awkward input, or only the path they expected?
Push Must first and keep the After freeze list off the board until features stop. A runnable happy path with a top comment beats a half-built feature list. Hitting Must alone is enough to proceed to the swap.
Point slower starters at the optional scaffold: one input, then if/else or list, then print. Get them typing within two minutes. If helpful, sketch that three-step shape on the board so nobody waits for a pasteable file. For support students, you can pre-seed a starter file with those three comment headings already pasted.
About halfway through the build (around 9 minutes in), call a quick checkpoint: "happy path runs once, even if it is ugly." Anyone still stuck on design gets redirected to the three-step scaffold so they still have something to swap.
If someone is stuck on syntax, point them at the error message and the line first. Do not type the fix for them unless the clock is tight and they have already formed a hypothesis.
About five minutes before the swap, call a freeze on new features. Only then point students at the After freeze list so polish does not compete with the core path. A student whose program only handles the normal path still goes to user test; they improve from what the tester does.
Before this step ends, write the cross-group test pairs on the board so the step 4 swap is instant and nobody burns minutes finding a partner.
Test with someone who did not build your program. Keep to this pace so you finish the improve step:
- Swap seats or devices with your assigned classmate. Do not explain how your program works.
- Silent try: watch them use it for about two minutes. Notice where they pause, what they type, and what confuses them. Stay quiet on the first attempt.
- Feedback note: write one thing that worked and one thing that did not.
- One fix and re-run: take your own program back. Make one improvement based on what you saw (clearer wording, a better error message, a missing case, or a comment that would have helped). Run it once more to check the change.
Done looks like:
- someone else has tried your program without a guided tour
- you can name one thing they struggled with or liked
- you have made and re-tested one change from that observation
If the program crashed for the tester, your one improvement is to fix that crash. Use their first action as the case you reproduce and repair, then re-run.
Pairs should already be on the board from the end of the build step so swap is about 1 minute, not a hunt for partners. Timebox on the board: about 1 minute swap, 2 minutes silent try, 1 minute feedback note, 4 minutes one fix and re-run. Protect the fix/re-run block; call the transitions so improve is not squeezed out.
Pair across usual groups so the tester is genuinely cold to the program. The builder must stay quiet during the first attempt; the point of LO 3.8 is observation, not coaching.
If numbers are odd, make one group of three and rotate. If a program will not run at all, the tester still gives feedback on the opening comments and what they expected; the builder spends the improve time fixing the crash from the tester's first action as the repro case. Keep the crash-fallback as the default improve path when something breaks.
Keep the improve step to one change. Students who chase a rewrite will miss the close.
A program that only works for its author is not finished. Watching a cold user is how you find the gap between what you meant and what the code actually does.
Documentation, clear names and a short ethical note are part of the build, not extras added at the end. They are what let someone else run, judge and trust your work.
Take two or three quick voices only: one improvement that came from the tester, one ethical issue someone named, one moment where a comment or clearer prompt would have saved confusion. Then move to reflect.
Unlock the full learning experience
You're previewing this lesson. Get full access to this lesson and hundreds more — each one ready to teach, with interactive activities, printable resources and pupil progress tracking built in.
This lesson is copyright of Coding Ireland 2017 - 2025. Unauthorised use, copying or distribution is not allowed.