Last year every task named a person. That has not changed, and it never will in this room: code is a vehicle for helping people, and a program nobody asked for is a hobby.
What changes in Grade 12 is that you stop working alone. The tasks escalate in three directions at once. You model the problem instead of only processing it. You choose algorithms and containers and defend the choice with evidence rather than habit. And from Unit 3 onward you build with other people, in a shared history, reviewing each other’s work — and you finish by giving the whole thing away to somebody who was never in the room.
The hardest new skill in this course is not writing code. It is being useful inside code somebody else wrote. Two of the tasks below exist entirely for that.
Every success-criteria table below is published on the day the task launches and traces back to our Learning Goals; Judging Your Own Work is how you use one while there is still time to change something. Working periods are class time, and what you do in them is evidence — How Marks Work explains which kind, and why it is not a mark for looking busy. The evidence of your thinking lives in your Code Journal, which every task collects from, and which in the team project is part of how your individual contribution is seen at all.
The tasks of the semester
- The Model — one class that models something real, plus the defence of every attribute you kept and the five you rejected.
- The Structure Study — one problem solved three ways, measured, with a recommendation you can say out loud and defend.
- The Efficiency Case — one slow program made fast, timed properly, and argued as an environmental case rather than a technical one.
- The Software Project — the culminating project: a real community partner, a team build across Units 3 and 4, version-controlled and reviewed, ending in a handover that outlives you.
- The Maintenance Sprint — a working program your team did not write: read it, test it, fix it, extend it, break nothing.
- The Frontier Report — one topic at the edge of the field, reported and defended in a seminar without notes.
The final evaluation
- The Handover — your partner runs the software, the package changes hands item by item, and the project gets a named next owner.
- Final Examination — three hours at the end of the course, on paper: reading code, writing it, judging algorithms, and the questions about computing and society that have no code in them at all.