02 — Lab Notebook

The single highest-leverage habit for a returning developer. Not a diary. Not a blog. A calibration instrument.

Every serious learning session opens with a prediction, closes with a measurement, and records the delta. Over 13 months this delta log becomes the map of what your brain has actually re-learned versus what it merely feels like it remembers.

This matters more for you than for a fresh beginner. A beginner does not have false confidence. You do. Two years of AI-assisted coding has installed a layer of fluency without recall — you read C++ and think “yes, of course, std::move invalidates the source” but when you sit at a blank editor you cannot say precisely when, why, or what the source looks like afterward. The lab notebook surfaces those gaps.

The core loop

  1. Hypothesis — what am I trying to learn or verify right now? (1 sentence)

  2. Prediction — before running the code, write what you expect to happen. (1 sentence)

  3. Measurement — run the code. Record what actually happened. (1–2 sentences)

  4. Delta — the difference between prediction and measurement. (1 sentence)

  5. Lesson — the durable rule you’d tell a peer. (1 sentence)

Five lines. That is a complete lab-notebook entry. Do not let it grow. If it wants to grow, split it into two entries.

Template

----------------------------------------
Date: 2026-07-14
Sprint: S1
Context: P0.2 tiny-vector implementation, task 4 (move ctor)

H: How does default move-ctor behave on a class that
   holds a raw pointer + size_t?

P: I expect the pointer to be copied bitwise and the
   moved-from object to still hold the pointer,
   causing a double free on destruction.

M: Ran it. Program double-freed and crashed with a
   "pointer being freed was not allocated" from malloc.
   Prediction was correct.

D: 0 (prediction matched measurement).

L: Default move-ctor on a raw-owning class is unsafe.
   Either (a) declare move-ctor manually and null the
   source pointer, or (b) use unique_ptr so the compiler
   generates a correct move for you.
----------------------------------------

When prediction is WRONG, the delta line is where you learn the most:

D: I thought vector::push_back would always double
   capacity. It actually grew 1.5x on libc++ (macOS).
   That's a libstdc++ vs libc++ growth-factor difference
   I had forgotten existed.

That delta is worth 20 pages of a textbook.

Where to keep the notebook

Recommended: hybrid paper + digital.

  • Paper notebook (small, A5, dotted or grid) sitting on your desk. Every session, entries go here first. Writing by hand slows you down enough to actually make the prediction instead of skimming past it.

  • Digital sync once a week, Sunday audit slot. Copy the week’s entries into LAB_NOTEBOOK.md in your primary repo, or a Dendron/Obsidian vault. Digital enables search across 13 months of entries.

Alternative if paper is not your thing: a single LAB_NOTEBOOK.md per sprint in the repo. Enforce the 5-line structure. If you catch yourself writing paragraphs, you are journaling, not calibrating — stop and re-write in 5 lines.

Frequency

  • Minimum: 1 entry per sprint (12 hours of work minimum = one real gap surfaced).

  • Target: 2–3 entries per week.

  • Ceiling: 1 per session. If you’re writing 5 entries per session, they are too small — fold them.

Do NOT write an entry for every trivial thing (“prediction: cout prints. measurement: it printed.”). Reserve it for moments where you had a real belief being tested. If you already know the answer with 90%+ confidence, skip the entry.

Why prediction matters more than measurement

The temptation, especially with AI tools nearby, is to skip straight to “run and observe.” This trains your brain to be a validator of code output instead of a generator of code hypotheses. In an study, in a debugging session at 2 AM, in a systems design conversation — you need to be the generator. You need to be able to say “I expect this to segfault because X” before running it.

The act of writing the prediction — in ink or in text, but out of your head and into a fixed form — is what forces the generator to fire. Everything else is aftermath.

Weekly digest — Sunday audit slot

Every Sunday during the audit (see 07_motivation_sustainment.md), spend 5 minutes reviewing this week’s entries. Ask:

  1. How many predictions were wrong? (Aim for at least one. If zero, you are only writing entries where you already know the answer — raise the difficulty.)

  2. What is the biggest delta from this week? (Star it. This is a candidate for a 05_teach_to_learn.md post.)

  3. What pattern do the wrong predictions share? (e.g. “I keep underestimating undefined behaviour in signed integer overflow.”) Feed this into next sprint’s daily-practice topic (04_daily_practice.md).

Anti-patterns

  • Post-hoc predictions. Writing the prediction after seeing the answer. This defeats the entire mechanism. If you realise you’ve already seen the output, skip the entry — do not lie to the notebook.

  • Vague predictions. “I think it will do something weird” is not a prediction. “I expect a compile error at line 12 because foo is not a member of Bar” is.

  • Growth to essay length. The notebook is not a blog. Blog posts come from starred deltas (see 05_teach_to_learn.md).

  • Missing lessons. Every entry must end with a lesson line. If you cannot state the lesson in 1 sentence, you have not finished the entry.

The 13-month payoff

At M13, when you sit in an study and the study partner asks “tell me about a hard C++ bug you debugged,” you do not reach into memory — you reach into the notebook. Six hundred entries, roughly. Fifty starred deltas. Ten of those are study-grade stories. That is your unfair advantage over the candidate who spent 13 months reading blog posts.