Roadmap

The duration arithmetic, the dependency structure, the six stages, and thirty-four monthly milestones.

Table of Contents

• Duration Derivation
• Dependency Graph
• Why This Order
• Legal Reorderings
• The Six Stages
• The Active-Week Schedule
• Monthly Milestones (M1–M34)
• Checkpoint Reviews
• References

Duration Derivation

Step 1 — effort per project

Each project's hour figure is the sum of its milestones, estimated at the pace of a senior engineer who knows the language but not the domain, and excluding optional research extensions. The full milestone breakdown is on each project page; the totals:

Step 2 — active weeks to calendar time

\[ \text{calendar months} = \frac{H}{W_{\text{prod}} \times p} \times 12 \]

where \(H = 1430\) hours, \(p\) is your sustained weekly pace, and \(W_{\text{prod}} = 46\) is productive weeks per year. Forty-six, not fifty-two, because six weeks a year vanish into travel, illness, a launch at work, and the fortnight after any real production incident. A plan that assumes fifty-two productive weeks is not optimistic, it is arithmetically wrong.

Step 3 — the honest verdict

34 months. Your stated ceiling of 30 months is reachable two ways, and only two:

• Sustain 12 h/week for the full scope — 1,430 h / 552 h per year → 31 months, with no margin for a bad quarter.
• Stay at 11 h/week and take the six scope cuts listed in the README — 1,265 h / 115 active weeks → exactly 30 months.

Anything shorter is achieved by deleting projects, not by working faster. If you want a shorter honest journey, the right cut is P01, P02, P04, P05, P13 and P15 only — six projects, 660 hours, 60 active weeks, ≈16 months at 11 h/week — which still covers a Transformer, an ANN index, a storage engine, a distributed system, an autodiff framework and an integrated contribution. That is a real 16-month plan. A 16-month plan containing all fifteen projects is not.

Dependency Graph

Solid arrows are hard dependencies: the downstream project consumes the upstream project's code or its measured results. Dashed arrows are soft: the downstream project is much easier if you have done the upstream one, but does not import it.

 STAGE 1              STAGE 2               STAGE 3            STAGE 4         STAGE 5      STAGE 6
 foundations          storage & exec        distributed        product         low-level    contribution

 P01 Transformer
   │  ┊
   │  ┊ (motivates)
   ▼  ┊
 P13-I Autodiff ───► P13-II Exec Opt ──────────────────────────────► P14 HW-aware ─┐
   │                                                                       ▲        │
   └───────────────────────────────────────────────────────────────────────┘        │
                                                                                    │
 P02 ANN index ────► P03 Vector DB ─────────────────────────────────────────────────┤
   │                    │  ▲                                                        │
   │                    │  ┊ (persistence borrowed from)                            │
   │                    │  ┊                                                        │
   │                 P04 LSM engine ──► P05 Distributed KV ──► P06 MapReduce         │
   │                                          │      ▲              │               │
   │                                          │      ┊              ▼               │
   │                                          │      ┊         P07 Streaming ───────┤
   │                                          │      ┊              │               │
   │                                          └──────┴──────────────┘               │
   │                                        (fault injector, reused by both)        │
   │                                                                                │
   └──────────────► P08 Recommender ──► P09 Simulator ──► P10 A/B platform ─────────┤
                          ▲                                                         │
                          ┊ (embeddings from)                                       │
                          ┊                                                         ▼
                      P01/P13                                            P15 Integrated System
 P11-I Tree-walk ──► P11-II Bytecode VM ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
                          ┊
                          ┊ (GC + dispatch intuition feeds the kernel)
                          ▼
                      P12 Kernel

Edge table

Every edge, with the specific thing that crosses it. An edge with no concrete payload is not a dependency, it is a vibe, and it should not constrain your ordering.

Critical path

Because you run one project at a time, the schedule is 130 sequential weeks. But the longest chain of true dependencies is only 51 weeks:

P04 (9) → P05 (13) → P06 (8) → P07 (8) → P15 (13) = 51 weeks

Two other long chains:

P02 (7) → P03 (8) → P08 (6) → P09 (6) → P10 (4) → P15 (13) = 44 weeks
P01 (8) → P13-I (6) → P13-II (4) → P14 (7) → P15 (13) = 38 weeks

That 51-vs-130 gap is your reordering budget. It means the sequence below is one valid topological order out of very many, and if life makes a particular project impossible this quarter, you can almost always slide it without breaking anything. See Legal Reorderings.

Why This Order

Three ordering decisions are non-obvious and worth defending, because you will be tempted to undo all three.

1. The Transformer comes first, before the autodiff framework it logically sits on top of.

The logical order is backwards. You should build tensors, then autodiff, then a model. The roadmap does the reverse, deliberately:

• Motivation survives contact with difficulty better than logic does. Week 1 of a Transformer produces a model that generates text; week 1 of an autodiff framework produces a class that can add two arrays. You are 130 weeks from the end and the first eight weeks decide whether there is a week nine.
• Building autodiff after you have used loss.backward() a hundred times converts the project from "implement a thing described in a blog post" to "explain a thing you have already relied on". That is the reconstruction skill this whole track is for.
• P13's exit criterion is concrete precisely because P01 exists first: your autograd must reproduce your Transformer's gradients to 1e-5 against PyTorch. Without P01 there is nothing to check against.

2. The vector database comes before the LSM engine, even though it needs persistence.

You will build a naive append-only file with a full in-memory index in P03, measure its recovery time at 1M vectors, watch it take minutes, and then build the LSM engine in P04 knowing exactly which problem sparse indexes and Bloom filters solve. Doing P04 first would give you a better P03 and a worse education. This is the single clearest instance of the "naive design first" rule at the level of the roadmap itself, and it costs roughly 6 hours of rework in P03 — a price the plan pays on purpose.

3. The kernel comes at month 27, not month 3.

Kernel work is the most likely project to consume unbounded time and the least likely to produce a portfolio artifact anyone can evaluate. Putting it late means you arrive with two years of scoping discipline, an existing benchmark harness, and a working definition of "done". Putting it early means you spend four months on a bootloader and quit.

Legal Reorderings

Given the dependency table, these swaps are safe. Anything that preserves the edge directions is legal; these are the ones you are most likely to want.

Two things that are not legal:

• Starting P15 before at least six upstream projects have passed their exit criteria. P15 is an integration and a research question; integrating three half-built systems produces a demo, not a contribution.
• Running two Large projects concurrently. Ever. This is the guardrail that the entire program is structured around.

The Six Stages

Stage 1 — Foundations and Reconstruction · W1–W26 · 286 h · M1–M7

Theme: learn the loop on projects where correctness is cheap to check.

Everything in this stage is single-process, single-machine, and deterministic. That is the point: you are learning to write a naive design, predict its failure, instrument it, and report on it, and you should not be simultaneously learning to debug a network partition.

Stage exit: four technical reports; four repositories another engineer can clone and reproduce; the benchmark harness is now yours by muscle memory.

Stage 2 — Storage and Execution · W27–W54 · 308 h · M8–M15

Theme: durability, amplification, and the cost of a byte moved.

Stage exit: you can explain read/write/space amplification with your own numbers, and you have twice built a thing whose performance is dominated by data movement rather than instruction count.

Stage 3 — Distributed Systems · W55–W83 · 319 h · M15–M22

Theme: partial failure. The hardest stage; budgeted accordingly.

Stage exit: a linearizability checker that has found at least one real bug in your own code, and a written failure analysis of a split-brain you caused on purpose.

Stage 4 — Product and Experimentation Systems · W84–W99 · 176 h · M23–M26

Theme: systems whose correctness is statistical, not logical. This is where your existing domain knowledge is deepest, so the stage is short and the bar is high — you should be producing near-publishable work here.

Stage exit: a documented case where an offline metric improved and the simulated online metric did not, with an explanation of the mechanism.

Stage 5 — Low-Level and Hardware-Aware Systems · W100–W117 · 198 h · M27–M31

Theme: the layers your abstractions have been standing on for four stages.

Stage exit: you can answer "why is this kernel memory-bound" with a measurement rather than an opinion, at every level from L1 to HBM.

Stage 6 — Original Contribution · W118–W130 · 143 h · M31–M34

Stage exit: the paper is written, the repository is reproducible from a clean machine by someone who is not you, and the negative results are in the paper rather than in a drawer.

The Active-Week Schedule

 Stage 1  W1 ─────────────────────────────── W26
          [P01 ·8·][P02 ·7·][P11-I 5][P13-I 6]

 Stage 2  W27 ────────────────────────────── W54
          [P03 ·8·][P04 ··9··][P11-II 7][P13-II 4]

 Stage 3  W55 ────────────────────────────── W83
          [P05 ·····13·····][P06 ·8·][P07 ·8·]

 Stage 4  W84 ────────────── W99
          [P08 6][P09 6][P10 4]

 Stage 5  W100 ─────────────────── W117
          [P12 ····11····][P14 ·7·]

 Stage 6  W118 ───────────── W130
          [P15 ·····13·····]

Monthly Milestones (M1–M34)

Calendar months, each covering ~3.8 active weeks at 46 productive weeks/year. The milestone column is the thing that must exist by month end — not a topic covered, an artifact that exists on disk and runs.

Checkpoint Reviews

At each stage boundary — M7, M15, M22, M26, M31 — stop for one full session (3 hours) and do this, in writing, in notebook/stage-N-review.md:

1. Score every project of the stage on the scorecard. Twelve categories, 1–5, with the evidence for each score named. Score down when unsure.
2. Recompute the schedule. Actual hours spent vs. planned. If you are more than 15% over, do not "try harder" — cut scope from the next stage using the cut table, and record what you cut.
3. Answer the four questions: What did I build that I could not have built at the start of this stage? Which of my predictions were wrong, and was there a pattern in how they were wrong? What did I avoid because it was hard? What is the single weakest of my twelve scorecard categories, and what specific mechanic in the next stage will train it?
4. Re-read one report from the previous stage. You will find an unsupported claim. Fix it or retract it.
5. Update Research Directions with anything you saw that might be novel. One line each. Do not chase it now.

The review is not optional and it is not a formality. It is the only mechanism in the program that catches slow drift, and slow drift over 34 months is the failure mode that actually ends journeys like this one.

References

• Brooks, F. P. The Mythical Man-Month, anniversary ed. Addison-Wesley, 1995. Chapter 2 on scheduling estimation, and the observation that adding effort to a late project makes it later — which is why the response to slipping here is scope cuts, not hours.
• DeMarco, T., Lister, T. Peopleware: Productive Projects and Teams, 3rd ed. Addison-Wesley, 2013. On sustained-pace work and the cost of interruption; the source of the 46-productive-weeks assumption.
• Hofstadter, D. R. Gödel, Escher, Bach. Basic Books, 1979, p. 152. Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law." The 34-month figure already includes one application of this; assume it needs a second.
• Boehm, B. W. Software Engineering Economics. Prentice-Hall, 1981. The cone of uncertainty: early estimates are reliably off by 4× in either direction, which is why every stage boundary here recomputes rather than reasserts.
• Lampson, B. W. Hints for Computer System Design. SOSP '83. "Keep it simple", "do one thing well", and the observation that most system complexity is unpaid-for generality — the intellectual basis for the scope-boundary section on every project page.