Your practice error log over 40 problems shows boundary mistakes clustering in grid problems - what do you change?

## From tally to decision An error log is worthless as a diary and valuable as an instrument. Its whole job is to convert a month of scattered attempts into one decision: *what do I practise for the next two weeks, and how will I know it worked?* A cluster - one error category showing up disproportionately in one shape of problem - is the instrument reading. The failure mode here is reading it, nodding, and then continuing to work through problems in whatever order they came. ## What an entry has to contain to be diagnostic A tally can only be as sharp as its entries. "Bug" is not a category. A usable entry records, per attempt: the *shape* of the problem (two-dimensional traversal, sequence with a moving window, dependency ordering); the pattern you chose; the outcome; the error class if any; and the moment it went wrong. The error class needs to name a cause, not a symptom - "read past the last column" is a cause, "wrong answer" is a symptom. Symptom-level logging produces a tally that is technically accurate and completely undecidable. ## Counts lie, rates do not Before acting on a cluster, normalise it. If half your recent attempts were grid problems, a majority of your errors appearing there tells you nothing - it is just where you spent your time. The number that matters is errors *per attempt* in that shape versus the others. A cluster is real when the rate stands out, not the count. This matters twice: once when you diagnose, and again two weeks later when you measure, because a targeted drill deliberately skews your attempt mix toward the shape you are fixing. If you compare raw counts across those two periods you will conclude that you got worse. Also mind the sample. Forty attempts is enough to notice a lopsided pattern and not nearly enough to rank five categories confidently. Act on the one clear outlier; do not build a five-point improvement plan out of noise. ## Is the cause the one you think it is? Before drilling, read the individual entries behind the cluster and check that they share a cause. Boundary mistakes on grids can come from at least three different places: getting the edge condition wrong on the index arithmetic; forgetting that the degenerate shapes exist at all; or choosing an approach whose bookkeeping is heavier than it needed to be, so there were simply more boundaries to get wrong. The first is a care gap, the second is a case-enumeration gap, the third is really *wrong pattern chosen* wearing a boundary error's clothes. Same tally line, three different remedies. This is why the entries, not just the tally, get re-read. ## Designing the drill A targeted drill has three parts. **Selection.** Choose problems specifically because they have the shape that provokes the error, densely, over a short period. Massed practice on one deficit is exactly right for closing it; you can re-interleave shapes afterwards to check that the fix survives mixing. **A procedural change, not just repetition.** Repetition without a changed procedure re-runs the same failure. Derive one concrete rule from the cause and apply it on every attempt: write the degenerate inputs down before writing any code; state the valid index range as an explicit half-open interval and check every access against it; run the smallest and largest legal input by hand before submitting. The rule should be small enough that you actually do it under time pressure. **A stopping condition.** Two weeks, or a fixed number of attempts, then you look again. Open-ended "work on boundaries" never terminates and never gets evaluated. ## Reading the second tally Three outcomes, three responses. The rate dropped: the cause was identified correctly; drop back to a mixed diet and re-check in a month, because a fix that only holds under massed practice has not transferred yet. The rate held: your remedy did not touch the cause - go back to the entries and look for the misdiagnosis, most often a recognition gap logged as a mechanical one. The rate dropped but a different category rose: usually real, and usually because the new procedure ate time or attention; that is a genuine tradeoff to notice rather than a regression to panic about. ## The habit this replaces The default alternative is counting problems finished. That number always goes up, is always encouraging, and is nearly uninformative, because it does not distinguish an attempt that taught you something from one that re-confirmed a skill you already had. A category tally with rates attached is harder to keep and is the only version that can tell you to change course.