At a glance
Individual · ongoing all course · an entry every time a period ends with “log it” · collected once in each unit
What you are making
A developer’s log of your course: a short entry written in the last minutes of class, whenever a period ends with “log it”, while the details are still warm. Ten honest minutes beats thirty performed ones — and entries are private. I read them; other students never do. The journal only works if you can admit in it what you would not say at the demo table — that the loop still feels like luck, that you froze when the traceback appeared.
How entries work
Each entry answers four prompts, in whatever order helps:
- What I built — the facts, briefly: the program, the feature, where your pair got to before the bell.
- What broke — the specific bug, in its own words. Paste the error message or a screenshot; a traceback captured the day it happened is the best artifact this journal collects.
- What I learned — the fix and why it worked, or the concept that clicked and what did the clicking.
- What I would try next — one concrete move for next class. Not “get better at loops”: something you could actually type.
Code fragments and screenshots are welcome any time — three broken lines with a sentence about the fix beats a paragraph of summary. Even a one-line hypothesis is a perfect journal sentence: “I think my loop runs once too many because the range is off by one” — dated, testable, and yours.
Success criteria and collection
The journal comes in once each unit, read against these criteria — Journal Checklist turns them into a self-check before handing in.
| Quality | What it looks like |
|---|---|
| Written from the day | Each entry names the actual moment — the line, the error, the thing that clicked — rather than summarising the period |
| Honesty | Real breakage recorded, not just victories |
| Precision | Bugs located and quoted, not just felt |
| Growth | ”Try next” items reappear as things actually tried |
The entries I read against those criteria are the in-class ones. What you add afterwards at home — a second thought at eleven at night, the fix that finally worked on the bus — is yours, is often the best writing in the book, and is not marked. How Marks Work explains why practice between classes is never the thing a mark is put on.
Curriculum connection
B2.1
use file management techniques, including those related to local and cloud storage, to organize, edit, and share files
Link to original
C2.6
interpret program errors and implement strategies to resolve them
Link to original