Operating Model
The weekly rhythm, the time allocation, the recurring thinking exercises, and the guardrails. This is the part of the plan that runs every week for 130 weeks.
Table of Contents
- The Weekly Unit
- The Weekly Allocation
- When To Adjust the Allocation
- A Week, Concretely
- Thinking Exercises
- Breadth-Control Guardrails
- The Three-Slot Rule
- Weekly Review
- References
The Weekly Unit
Weeks 1–12 are written out in First 12 Weeks; from week 13 you produce them yourself with The Week Generator.
Every week produces six things. Not five, not "roughly". If a week ends without all six, the week is incomplete and the reason goes in the log.
| # | Output | Why it is non-negotiable |
|---|---|---|
| 1 | One primary objective | Written on Monday, one sentence. A week with two objectives has none |
| 2 | Implementation work | Code that runs. The largest block of the week |
| 3 | Limited required reading | Bounded, tied to the current milestone. Reading is an input, never an output. Protocol: How To Read |
| 4 | One experiment or test | With a prediction recorded before it runs |
| 5 | One written reflection | 200–400 words. What I expected, what happened, what I learned |
| 6 | One concrete deliverable | Something that exists on disk and did not exist Monday |
The reflection is the one that gets skipped and the one that carries the compounding. Over 130 weeks it becomes a 40,000-word record of your own reasoning improving, and it is the only artifact in this program that cannot be reconstructed later.
Reading never completes anything. A week whose deliverable is "read the Raft paper" is a failed week. The deliverable is "election timeout implemented and tested"; the paper is how you got there.
The Weekly Allocation
At 11 hours per week:
| Activity | Share | Hours | What it covers |
|---|---|---|---|
| Foundational reading | 15% | 1.65 | Papers, book chapters, source of other systems |
| Implementation | 45% | 4.95 | Writing code. The core |
| Experimentation and benchmarking | 20% | 2.20 | Running, measuring, plotting |
| Technical writing | 10% | 1.10 | Notebook entries, report sections |
| Review, debugging, reflection | 10% | 1.10 | Including the weekly review and the 10-minute review queue |
Two observations that make this allocation work:
Experimentation is a separate budget from implementation. If it is not, it does not happen — measurement always loses to the next feature when they share a bucket. Two hours a week, protected, is what makes this a research journey rather than a build log.
Writing is 10% and it is scheduled, not opportunistic. One hour a week produces a report per project without a crunch at the end. Writing at the end of a project means writing about work you have forgotten the details of.
When To Adjust the Allocation
The default is not right for every project. Adjust deliberately, and record it in the weekly log so that a slow week is diagnosable.
| Situation | Adjustment | Applies to |
|---|---|---|
| Mathematically heavy start | Reading 15%→30%, implementation 45%→35%, for the first 2 weeks only | P13 Phase I (chain rule, Jacobians), P10 (power and inference) |
| Deep distributed theory | Reading 15%→25% for weeks 1–3 of the project | P05 (Raft, FLP, linearizability) |
| Debugging-dominated phase | Debugging 10%→25%, taken from implementation | P05 mid-project, P12 boot phase |
| Experiment-heavy phase | Experimentation 20%→35%, taken from implementation | Final 2 weeks of every project |
| Report weeks | Writing 10%→40% | Final week of every project |
| A stage-boundary week | Review 10%→100% for one session | M7, M15, M22, M26, M31 |
Never adjust implementation below 30% for more than two consecutive weeks. Below that you are studying, not building, and the failure mode this whole program exists to prevent has quietly resumed.
A Week, Concretely
An example week at 11 hours, split as 2 hours on four weekdays and 3 hours on a weekend day. This is a shape, not a prescription — adapt it to when you actually have energy, which for most people is not Thursday evening.
| Session | Hours | Content |
|---|---|---|
| Mon | 2.0 | Write the week's objective (10 min). Read the milestone's assigned paper section (1 h). Implementation start (50 min) |
| Tue | 2.0 | Implementation |
| Wed | 2.0 | Implementation, ending with the code in a state that can be measured |
| Thu | 2.0 | Write the experiment prediction first (15 min), then run the experiment, then record results (1 h 45 min) |
| Sat | 3.0 | Debugging and cleanup (1 h) · notebook entry and reflection (1 h) · weekly review and next week's objective (30 min) · buffer (30 min) |
Three properties of this shape matter more than the specific days:
- Reading is at the start of the week and bounded. Reading in the middle of an implementation block always expands to fill it.
- The experiment has its own session and begins by writing the prediction. If the prediction and the run happen in the same session, write the prediction in a file and commit it before running anything.
- The weekend session ends with next week's objective already written, so Monday starts with action rather than orientation. Deciding what to do costs more energy than doing it.
The 30-minute session
Some weeks you get 30 minutes instead of 2 hours. There is a defined use for it, so that a short session is not a lost one:
- Re-read the last notebook entry (5 min)
- Do exactly one thing: fix one test, write one function, plot one graph (20 min)
- Update the log with where you stopped and what is next (5 min)
Step 3 is what makes it worth doing. See the resumption cost.
Thinking Exercises
Twelve questions. Not a checklist to run weekly — that turns them into a ritual. Instead, each is attached to a trigger, so it fires when it is useful.
| Question | Trigger |
|---|---|
| How would I solve this if the canonical solution did not exist? | Before reading any paper about the thing you are building. This is step 3 of the loop |
| Which assumption is doing the most work? | When a design feels obviously right. The obviousness is usually an unexamined assumption |
| What scale or workload breaks this design? | Before every "it works" claim |
| What result would prove my idea wrong? | Before every experiment. If you cannot answer, the hypothesis is not falsifiable and the experiment is theatre |
| What variable am I failing to measure? | When results are unexplained. In P02 it was distance count; in P07 it was state size. There is almost always one |
| Is the bottleneck computational, algorithmic, architectural, or operational? | Before optimising anything. Four different answers, four different fixes |
| What is hidden by the current abstraction? | When something is unexpectedly slow, or unexpectedly fast |
| Can I reduce this to a smaller model? | When stuck for more than two sessions. Almost every bug reproduces at 1/100 scale |
| What happens under skew, failure, concurrency, and partial information? | Before declaring any component done |
| Which performance gain is merely moving cost elsewhere? | After every speedup. Caching moves cost to memory; batching moves it to latency; async moves it to complexity |
| Can another engineer reproduce this result? | Before writing any report |
| What did the failed experiment teach me? | After every failure, before moving on. The answer is never "nothing" |
The one to internalise first
Which performance gain is merely moving cost elsewhere?
Almost every optimisation in this journey is a relocation, not an elimination. Bloom filters move disk I/O to RAM. Compaction moves read cost to write cost. Batching moves latency to throughput. Quantization moves accuracy to speed. Caching moves consistency to speed. Speculative execution moves wasted CPU to reduced tail latency.
An engineer who asks "where did the cost go?" after every improvement develops a different and more accurate model of systems than one who collects speedups. Ask it every time.
Breadth-Control Guardrails
Fourteen failure modes, each with the mechanism that prevents it. A guardrail without a mechanism is a good intention.
| Failure mode | Preventing mechanism |
|---|---|
| Starting multiple large projects simultaneously | The three-slot rule, enforced by the weekly log's three named lines |
| Abandoning a project when it gets hard | The two-week stall rule: scope cut and a written postmortem, never silence |
| Spending weeks collecting resources | Reading is capped at 15% and every reading is tied to a named milestone. No general reading lists |
| Turning each project into a production-grade product | Every project page has an explicit Scope Boundaries section listing what is out |
| Hiding mechanics behind frameworks | Every project page has a permitted-library line naming what may and may not be imported |
| Optimising without a baseline | Step 8 of the loop precedes step 11. Exit criteria require a baseline |
| Benchmarking only unrealistic workloads | Every project's experiments include a skewed or adversarial distribution |
| Reporting average latency without tails | bench.py reports p50/p95/p99 by default and there is no mean-only mode |
| Ignoring correctness while measuring performance | No performance work while a correctness test is red. Exit criteria list correctness first |
| Treating complexity as originality | The scorecard rewards falsified hypotheses and penalises unmeasured components |
| Confusing reading with progress | The weekly deliverable can never be a reading |
| Skipping written analysis | Writing has its own 10% budget and reports are exit criteria |
| Starting extensions before exit criteria | Extensions are locked. No downstream project ever depends on one |
| Constantly changing languages and infrastructure | Languages assigns one per project with a stated reason |
The Three-Slot Rule
At any moment you have exactly three slots, and the weekly log has exactly three lines for them:
PRIMARY : the one implementation project. All milestone work happens here.
SECONDARY : one small maintenance or writing task from an EARLIER project.
READING : one bounded thread that directly supports PRIMARY.
Rules:
- PRIMARY is one project. Not one project plus a small experiment on another.
- SECONDARY is bounded at 1 hour/week and must be from a project already past its exit criteria — fixing a bug someone reported, writing a blog post, improving a README. It is not a second project; it is maintenance.
- READING must name the milestone it serves. "Reading about consensus" is not a valid entry. "Raft §5.4.2 for milestone 7" is.
- A fourth interest goes on the parking list, one line, and is not touched. Review the parking list at stage boundaries; most entries will have stopped being interesting, which is the point.
The parking list is the pressure valve. The failure mode is not having ideas — it is acting on all of them. Writing an idea down and not doing it is a skill, and the list makes it a mechanical act rather than an act of will.
Weekly Review
Thirty minutes at the end of the last session of the week. Written, in
notebook/weekly/YYYY-WW.md.
## Week NN — <project> milestone <n>
OBJECTIVE (set Monday) : ...
MET? : yes / partly / no — and why
SLOTS
PRIMARY : ...
SECONDARY : ... (≤1 h)
READING : ... (names its milestone)
HOURS plan 11 / actual __
reading __ · implementation __ · experiment __ · writing __ · debug __
DELIVERABLE : <what exists now that did not on Monday>
EXPERIMENT
prediction : ... (written before the run)
result : ...
verdict : confirmed / falsified / inconclusive
REFLECTION (200–400 words)
What surprised me. What I got wrong and why. What I avoided because it was hard.
NEXT WEEK'S OBJECTIVE : <one sentence>
PARKING LIST ADDITIONS : ...
The "what I avoided because it was hard" line is the most valuable one. It is where you catch yourself doing the easy milestone out of order, polishing instead of debugging, or reading instead of writing. Over a 130-week program, that line is the early-warning system for drift, and drift — not difficulty — is what ends journeys like this.
References
- Ericsson, K. A., Krampe, R. T., Tesch-Römer, C. The Role of Deliberate Practice in the Acquisition of Expert Performance. Psychological Review 100(3), 1993. The source of the "practice with immediate feedback on a specific weakness" structure that the experiment-per-week rule implements.
- Hamming, R. W. You and Your Research. Bell Communications Research, 1986. On working with the door open, and on the compounding of consistent effort.
- Newport, C. Deep Work. Grand Central, 2016. The case for protected blocks and against fragmented attention; the source of the fixed-session structure.
- Boice, R. Professors as Writers. New Forums Press, 1990. The empirical finding that short daily writing beats binge writing on both volume and quality — the basis for the scheduled 10%.
- Lampson, B. W. Hints for Computer System Design. SOSP 1983. "Handle normal and worst case separately" applied to your own schedule: the 30-minute session is the worst-case path, designed rather than improvised.
- Allen, D. Getting Things Done. Penguin, 2001. The parking list is a next-actions list with one slot; the mechanism is the same and so is the reason it works.