By mid-course your Code Journal stops being only a log and becomes something rarer: evidence. The person who wrote your week-one entries does not quite exist any more, and because that person wrote honestly, you can prove it. Showing growth means putting your earliest self and your current self side by side and letting the difference speak.

Growth is a claim plus evidence — like a bug report

“I got better at programming” is a claim, and a claim on its own is worth nothing. A good bug report never says “it’s broken somehow”; it says what happened, where, and how to reproduce it. Growth writing meets the same standard: every claim backed by two dated entries from your own record.

In my second entry I wrote: “I froze completely looking at someone else’s forty lines.” Last Thursday I opened a module none of us had touched, ran it with an empty file, read the failing frame, and had the cause in six minutes. The forty lines did not get shorter.

The claim is reading somebody else’s code has become a method rather than a panic. The evidence is two moments, months apart, both on the record — and nobody can argue with that, including the part of you that suspects you have not changed.

Three kinds of growth this course can show

Grade 11 growth was mostly about what you could build. This year the record can carry more than that, and the strongest reflections use all three.

  • Building. The obvious one. Bigger programs, better structure, fewer things held together by luck.
  • Judgement. The entries where you chose between two designs and said why. Early entries tend to record what you did; later ones record what you decided, and the arrival of that word in your own writing is itself the evidence.
  • Working with other people’s code and other people. Reading a stranger’s module, taking a review without flinching, giving one that was about the code. This is the axis most students undersell, because it does not feel like programming until you notice how much of the term it consumed.

How to cite yourself

Treat your earlier entries the way an essay treats sources:

  • Date it. “In my entry from the second week…” The distance is part of the claim.
  • Quote a phrase, not a page. Your words at the time carry more truth than your summary of them now.
  • Then show the now. A recent moment, just as specific, that the earlier you could not have managed — or would not have noticed.

Your commit history is a second witness

The journal says what you thought; the repository says what you did, with dates nobody can adjust afterwards. A growth claim that quotes an early entry and points at a commit is about as strong as evidence gets in this course — and it is the same standard How Marks Work applies to everything: what can you point to?

Curriculum connection

A2.3

demonstrate the ability to modify existing modular program code to enhance the functionality of a program.

Link to original

B2.3

reflect on, and assess, team and individual progress during the project review.

Link to original

D4.3

research and describe careers associated with computer studies (e.g., computer scientist, software engineer, systems analyst), and the postsecondary education required to prepare for them;

Link to original

D4.4

evaluate their own development of Essential Skills and work habits that are important for success in computer studies, as identified in the Ontario Skills Passport.

Link to original