Skip to main content

Curriculum Execution Guide

This page turns the curriculum into an operating system. The roadmap tells you what to study. This guide tells you how to execute it without drifting, burning out, or mistaking reading for progress.

Operating Model​

Treat the curriculum as a long-running engineering apprenticeship with explicit outputs.

  • Unit of progress: one module
  • Cadence of execution: one week at a time
  • Proof of learning: notes, katas, quizzes, project artifacts, and a working repo
  • Gate to advance: checkpoint passed without hand-waving

You are not done with a module because you read it. You are done when you can explain it, implement it, and retrieve it later.

The default module path is concept study -> example -> drill -> retrieval -> application. Book reading is selective support, not the main definition of progress.

Weekly Rhythm​

Use a six-day execution cycle with one lighter recovery/admin block.

DayPrimary outcome
Day 1Warm-up quiz, first concept pages, initial notes
Day 2More concept pages, diagram redraw from memory, first kata
Day 3Practice page, practical implementation, test coverage
Day 4Remaining concept page or guided drill, second kata
Day 5Retrieval practice, Feynman note, spaced repetition cards
Day 6Quiz, repo cleanup, weekly journal, backlog triage
Day 7Light review, deck maintenance, rest or catch-up

Daily Session Template​

  1. 5-10 min spaced repetition review
  2. 5 min prerequisite activation or brain dump
  3. 45-90 min focused concept-study block
  4. 30-60 min drill, implementation, or kata block
  5. 10 min summary note and next-step planning

Aim for 10-15 focused hours per week. Below that, progress becomes fragile. Above 18-20 sustained hours, recovery needs to be planned deliberately.

Module Completion Standard​

A module is complete only when all of the following are true:

  • Warm-up quiz attempted honestly before study
  • Primary concept pages completed and rewritten into your own notes
  • All key concepts explained from memory in plain language
  • At least 2-3 katas or drills completed
  • Practical implementation finished in code
  • Retrieval practice done without notes
  • Feynman note written
  • Spaced repetition cards added to your review system
  • Module quiz completed and scored
  • One visible artifact committed to a repo or notes folder

Reading Policy​

Use source books only in these cases:

  • a module page marks a chunk or section as Read only if stuck
  • a module page offers an Optional deep dive
  • you have completed the concept page and still cannot explain the idea clearly

Do not treat "read the chapter" as the default completion standard.

Required Artifact Types​

Every module should leave behind at least one durable artifact:

  • notes/ summary or Feynman note
  • katas/ solutions
  • labs/ or exercises/ code
  • diagrams/ system or concept diagrams
  • anki/ exported cards or markdown card tables

If a module has no artifact, it was probably consumed, not learned.

Semester Completion Standard​

A semester is complete when:

  • Every public module meets the module completion standard
  • The semester project is finished and self-reviewed
  • The checkpoint is passed without heavy note dependence
  • The cumulative review is completed under time pressure
  • The exam is completed and graded against a rubric
  • Weak areas are written down with a remediation plan

Do not move to the next semester with unresolved checkpoint failures in prerequisite-heavy subjects like math, algorithms, systems, databases, or architecture.

Execution Flow By Stage​

Stage 0: Setup​

Before Semester 0:

  • Create one main workspace for the curriculum
  • Decide your primary implementation language for Semesters 0-3
  • Set up Git, editor, terminal, and a simple note system
  • Create an Anki deck structure or markdown card workflow
  • Create a weekly review slot on your calendar

Language Rule​

  • Use one primary language for Semesters 0-3 so fundamentals compound in one environment.
  • Use C where required in systems-focused semesters.
  • Return to your primary language for services, architecture, and capstone work unless there is a strong reason not to.
  • Avoid changing languages just to chase novelty.

Stage 1: Foundations​

Semesters 0-3 prioritize:

  • learning how to study
  • mathematical and algorithmic rigor
  • clear code and design judgment

Bias toward repetition, handwritten reasoning, and small implementation drills.

Stage 2: Systems Core​

Semesters 4-6 prioritize:

  • memory and machine models
  • OS and network behavior
  • persistence, indexing, transactions, and failure

Bias toward debugging, tracing, command-line work, and tradeoff explanations.

By the end of Semester 5, complete one small hosted deployment of a networked or service-style project. Do not wait until the cloud semester for your first real deployment experience.

Stage 3: Architecture To Production​

Semesters 7-10 prioritize:

  • architecture decisions
  • distributed systems tradeoffs
  • cloud delivery and operational readiness
  • shipping one capstone with production evidence

Bias toward design docs, diagrams, deployment, observability, and written decision-making.

Writing And Design Artifact Standard​

From Semester 2 onward, every semester should produce at least one structured engineering artifact beyond code and notes.

Acceptable artifacts include:

  • problem writeup
  • implementation note
  • design note
  • ADR
  • debugging report
  • performance note
  • postmortem
  • runbook

The artifact should explain a decision, tradeoff, failure, or investigation clearly enough that another engineer could follow the reasoning.

Buffer Week Rules​

Buffer weeks are structural. Use them in this order:

  1. Finish overdue deliverables from the previous semester.
  2. Re-pass weak checkpoint items.
  3. Clean notes, repos, and decks.
  4. Reduce fatigue before the next phase.

Do not start the next semester early unless all four are already done.

Project Execution Standard​

Each semester project should produce:

  • a scoped problem statement
  • explicit constraints and non-goals
  • a repo with readable history
  • a README with setup, decisions, and usage
  • tests appropriate to the semester
  • one short retrospective: what failed, what changed, what you would do next

From Semester 6 onward, every major project should also include at least one of:

  • architecture diagram
  • ADR
  • threat model
  • performance note
  • observability or operations note

Review And Remediation Loop​

At the end of each week, classify work into three buckets:

  • green: can explain and do without help
  • yellow: recognize but still need prompts
  • red: cannot reproduce or apply yet

At the end of each semester:

  • revisit all red items first
  • convert the top yellow items into cards or katas
  • carry at most 3-5 explicit remediation targets into the next semester

Do not carry silent gaps forward. Silent gaps become expensive later.

curriculum/
  notes/
    semester-00/
    semester-01/
  repos/
    s00-orientation/
    s02-algorithms/
    s04-systems/
    s10-capstone/
  diagrams/
  anki/
  journal/

The docs site is the curriculum. Your workspace is the evidence.

Final Rule​

Optimize for retention, execution, and evidence. If forced to choose, choose the workflow that leaves proof you can still perform the skill later.