At a glance
Individual · ongoing all course · one entry after every class · collected at the end of each unit
What you are making
A developer’s log of your course: one short entry after every class, written the same day while the details are still warm. Ten honest minutes beat 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, that you have no idea what your partner typed.
How entries work
Each entry answers four prompts, in whatever order helps:
- What I built — the facts, briefly. The program, the feature, where you and your partner got to before the bell.
- What broke — the specific failure, in its own words. Paste the error message or a screenshot. A traceback captured on the day it happened is the best artifact this journal collects.
- What I learned — the fix and why it worked, or the idea that finally 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 are welcome any time. Three broken lines with a
sentence about the fix beat a paragraph of summary, and even a
one-line hypothesis makes a perfect entry: “I think my loop runs one
time too many because range stops before the number I gave it.”
Dated, testable, and yours.
The client thread
From the moment you have a client, one extra line belongs in every entry: what I now know about the person I am building for. Not what you built — what you learned about them. A preference they mentioned in passing, a step in their week you had not imagined, the feature they politely did not care about. Those lines are impossible to reconstruct later and they are what make The Community App a program for somebody rather than a program in general.
Success criteria and collection
The journal comes in at the end of each unit and is read against these criteria. Journal Checklist turns them into a self-check you can run before handing it in.
| Quality | What it looks like |
|---|---|
| Regularity | An entry for every class, written close to the day |
| Honesty | Real breakage recorded, not only the victories |
| Precision | Bugs located and quoted, not merely felt |
| Growth | ”Try next” items reappearing as things actually tried |
| Audience | Evidence that you kept thinking about the person you build for |
Why any of this counts: see Mistakes Are Data, which argues that a broken build is not a confession but a finding — and findings belong in a log.