Most of what happens in a programming course evaporates as it happens. Programs get fixed and the broken versions vanish. That was true last year, and version control now rescues part of it — your commit history is a permanent record of what the code did and when.
What it cannot record is why. Why you chose a dictionary over two parallel lists. What the other three options were. What your teammate said in review that changed your mind. What you finally understood about the program you inherited, twenty minutes before the bell. None of that is in the repository, and none of it can be reconstructed later. Your journal is where it lives.
The hub is Code Journal. The pages below support it, roughly in the order you will need them:
| Page | When you need it |
|---|---|
| Your First Entry | Week one, facing a blank page |
| What a Strong Entry Looks Like | Once the habit exists |
| Journal Checklist | Before each unit’s collection |
| Judging Your Own Work | Mid-task, while there is still time to fix it |
| Showing Growth | Mid-course, when old entries become evidence |
| Final Reflection | The last week, reading the whole record |
The journal and the history are two halves of one record
Your commits say what changed. Your journal says why, and what you rejected. Together they are the only honest account of a team project — and they are what makes it possible to answer the question every student asks about group work, which How Marks Work takes head on.