At a glance
Solo · launched in Unit 1 and handed over three classes later · one short Python program, one named person, one page of notes · your first evidence that code can be useful to somebody who is not you
What you are making
A script that saves one real person a small amount of one repeated chore. Not an app. Not a menu system. A script — often fifteen lines, sometimes fewer — that asks a question or two, does the arithmetic or the checking that person currently does in their head, and prints an answer they can use.
Your person is real and you must name them: a parent who works out how much to buy, a coach who converts times, a sibling who is drilling vocabulary, a neighbour who splits a bill four ways every month, the teacher who runs the breakfast program. Ask them. Their words, not your guesses, define what this does.
Here is a complete example of the right size, written for a teacher who orders milk based on how many students ate breakfast:
students = int(input("How many students ate today? "))
cartons = students * 2
if cartons > 48:
print(f"Order {cartons} cartons — that is more than two cases.")
else:
print(f"Order {cartons} cartons.")That is genuinely small, and it is genuinely a pass — if the teacher actually uses it. Ambition in this task is spent on fit, not on size.
What must be in it
- A named person and, in one sentence, the chore in their words.
- Input typed by that person, processing you wrote, and output they can act on — the shape of every program you will build this year.
- At least one decision: something the program handles differently depending on the answer.
- Prompts a stranger could follow. No
ENTER VAL:. Ask a whole question, in whole words. - Comments and honest names, so that the version of you who opens this file in June still knows what it does.
How to work
- Ask your person what they do now, step by step, and write it down before you imagine any solution. If you find yourself proposing an app in the first minute, start again.
- Write the sentence: [Name] does [what], and the annoying part is [what]. Bring it to class.
- Start from the skeleton we build in class rather than an empty file: the input–process–output shape, with the thinking left to you. Starting from a Skeleton
- Sketch the conversation on paper — what the program asks, in order, and what it says back. Two minutes with a pencil saves twenty at the keyboard.
- Build the shortest thing that answers the question. Run it after every few lines rather than at the end.
- Test it as a stranger: type a word where a number goes and see what happens. You are not expected to survive that yet, but you are expected to know it happens.
- At the hand-off, a partner runs your script while you say nothing. Write down every hesitation. Fix exactly one.
How this is assessed
The mark follows How Marks Work: the working period is part of the task, so what I see you doing in class counts, and so does the trail you leave in your Code Journal. Two entries are expected — one after you talk to your person, one after the hand-off — and the second one is where the marks actually are, because that is where you write down what you watched somebody else struggle with.
Success criteria
| Quality | What it looks like in your script |
|---|---|
| A real person served | Your notes name them and quote their chore |
| Input, process, output | The program asks, works, and answers |
| A decision that matters | Different answers produce different advice |
| Written for a stranger | Prompts are whole questions; output is plain |
| Readable in June | Names say what they hold; comments say why |
| Honest hand-off | You logged what your partner hesitated over |
Reflect
Write a Code Journal entry after the hand-off. What did your partner do that you did not predict? What did your person say that you almost ignored? And the uncomfortable one: is there any chance this script sits unused after today — and if so, what would have had to be different?
If it feels too small to be worth marks
That reaction is the actual subject of this task. The instinct to build something impressive is exactly what makes so much software useless — it optimises for the builder’s pride rather than the user’s Tuesday. A fifteen-line script that a real person opens twice a week is a better piece of engineering than a two-hundred-line menu system that nobody opens twice. Read Who Is This For, then go make something small that gets used.
Curriculum connection
A2.1
write programs that incorporate user input, processing, and screen output;
Link to original
B2.1
design programs from a program template or skeleton (e.g., teacher-supplied skeleton, Help facility code snippet);
Link to original
A2.2
use sequence, selection, and repetition control structures to create programming solutions;
Link to original
B1.3
use the input-process-output model to solve problems.
Link to original
A4.2
use workplace and professional conventions (e.g., naming, indenting, commenting) correctly to write programs and internal documentation;
Link to original