The Editorial Protocol
Attempt-first editorial study: stall rule, observation-first reading, clean re-implementation, variation transfer.
The Editorial Protocol
Reading editorials badly is a skill leak: you nod, you move on, the next unfamiliar problem destroys you anyway. The protocol below turns an editorial into training.
The stall rule
Do not open the editorial until you have a stalled attempt: a concrete brute force written down, its bottleneck measured or clearly identified, and at least 30 minutes of real attack on that bottleneck. Reading after a real stall works; reading after five minutes teaches nothing.
Reading order — never linear
- Observation section only. Close the tab. Re-derive the algorithm from the observation alone.
- Complexity line. Does your derivation match? If theirs is O(n log n) and yours is O(n log² n), find the missing trick before reading code.
- Implementation only when stuck. The code is the last section. If you need it, you are copying an idea you have not understood yet — go back to step 1.
- Common wrong approaches. Read these even when you solved it: the near-misses are where the next contest's WA lives.
The re-solve
Close everything. Re-implement the solution from a blank editor. If you cannot, you read a solution; you did not learn an idea. Then solve the variation below — same core insight, different statement. If the variation stalls you again, the insight did not transfer; re-derive it.
Two worked examples ship with this module
Both follow the exact structure: Observation → Brute force → Why it fails → Key insight → Optimization → Complexity → Common wrong approaches. Use them as templates for post-contest editorial study — including self-written editorials for problems you did solve, which is how the proof habit forms.