Journal Checklist

Your Code Journal is collected at the end of each unit. Before you hand it in, run this check. It is the same lens I read with, so anything you catch here is something we never need to have a conversation about. Ten minutes with this list is usually worth more than one extra entry.

The check

Coverage

• There is an entry for every class in the unit
• Entries were written close to the day, not reconstructed the night before collection — reconstructed entries always show
• All four prompts appear across the unit: what I built, what broke, what I learned, what I would try next
• At least one entry includes a real artifact — a pasted error message, a code fragment, or a screenshot from the day

Quality

• Every bug is located, not just felt: “line 6 crashes on empty input”, not “my program was being weird” (see What a Strong Entry Looks Like)
• At least one entry records something that genuinely broke or confused me, not only the parts that went well
• My own part is named rather than hidden inside “we” — what I typed, suggested, spotted, or misread
• Help is credited where it happened: a classmate, a forum, an AI assistant, exactly as Our Classroom Norms asks

The person you build for

• Once a client exists, entries record something learned about them, not only about the code
• Anything the client asked to keep private stays out of the journal, or goes in without their name

Growth

• Each entry ends with one concrete “what I would try next”
• At least one earlier “try next” turns up later as a thing I actually tried, with a sentence about how it went

The last two boxes are the whole game

Anyone can write “I will read error messages more carefully.” The journal becomes evidence the day a later entry says “I read the whole traceback before touching anything and it named the exact line” — a loop from intention to attempt to result. That loop is what Showing Growth will ask you to point at, so leave yourself things to point at.