what to learn / in what order
Learn
The material that teaches the part a model cannot do for you: deciding what to build, specifying it so a machine can execute it, and checking the result. Work the stages in order, or jump to the one you are missing. Every stage mixes something you can follow along with and something worth returning to, and ends with a check you can run to know it landed.
- Watch and follow along. Short episodes, high production, low friction.
- Structured series with exercises, longer commitment.
- Read, with a voice rather than a specification.
- Interactive, you break something on purpose.
- Primary source, dense, worth the effort.
- Worked examples to read rather than a thing to study.
10 stages / 97 sources
Fluency
37The unglamorous prerequisites that make everything after it cheap. Do this first and the rest of the list takes half the time.
Shell, editors, version control, debugging, profiling. Taught as a series of live sessions, and the single best hour-to-value ratio on this list.
- 8-bit computerBen Eater
Build a working computer on breadboards, one episode at a time. The friendliest possible route into what a clock and a register actually are.
Forty short animated episodes. Watch it before the serious books and the vocabulary stops being a wall.
The Hard Parts, in full
Will Sentance's complete set, all in one register: a lecture where someone reasons in front of you, builds the mental model on a whiteboard, and drills it until it holds. Watch them in sequence rather than cherry-picking, because each one assumes the model the last one built.
Closures, async, OOP, and metaprogramming as a model of execution rather than a set of tricks.
Prototypal design, and how it enables ES6 classes under the hood.
Higher-order functions, composition, pure functions, and immutability.
Promises and async/await from the call stack, event loop, callback queue, and micro-task queue.
HTTP, TCP/IP, and ports from first principles, then the event loop, streams, and buffers.
Data binding, templating, virtual DOM and reconciliation, and hooks, all built from scratch. The clearest account of what React is actually doing.
Prediction and training from a basic decision model up to a neural network, with fraud detection and image recognition as the worked examples. Filed with stage 8's material too, but it belongs in this sequence.
Done when
You can start a project, commit, run it, break it, and read the error without leaving the shell.
Pair it with Watch the Hard Parts series in sequence, because each one assumes the model the last one built. Take Missing Semester first if the shell is still unfamiliar.
How the machine works
1121What a line of code actually does to the machine, and roughly what it costs. You can read an agent's output only to the depth you can read the machine underneath it.
- Nand to TetrisShimon Schocken, Noam Nisan
Build a computer from a NAND gate up through an operating system. The bottom rung done rather than described.
- CodeCharles Petzold
The same ladder in prose, and a different register. Read instead of Nand to Tetris if you want the map before the construction.
- Computer EnhanceCasey Muratori
The cost lens on the same machine: what a line of code costs and why.
- Structure and Interpretation of Computer ProgramsAbelson and Sussman
The deepest available treatment of what an abstraction is, free online, with the 1986 MIT lectures and OCW 6.001 alongside it.
- Why Don't People Use Formal Methods?Hillel Wayne
Read here rather than with the formal methods material, because it is the best short account of why a correct idea loses to a convenient one.
Done when
From reading one line, you can say what the machine does with it and roughly what it costs.
Pair it with Build it with Nand to Tetris, read Code for the map, then take SICP when you want to know what an abstraction actually is.
Deciding what to build
6How to work out what to build before any code exists: getting a requirement out of real users instead of guessing, and turning it into something you can check.
- The Mom TestRob Fitzpatrick
Customer conversations without the flattery. Short, funny, and the fastest read on this list.
- Shape UpRyan Singer, Basecamp
Free online, opinionated, and enjoyable. The appetite framing, fix the time and vary the scope, is the most transferable idea in it.
- Continuous Discovery HabitsTeresa Torres
Opportunity solution trees, with a blog that is easier to start with.
- Specification by ExampleGojko Adzic
Turning a decision into executable acceptance criteria.
- Domain Modeling Made FunctionalScott Wlaschin
Types as a specification of what is representable, the closest thing to a compile-time check on a requirement.
- Problem FramesMichael Jackson
No stable public URL, so cite by title. The best treatment of why the hard part of a requirement is the boundary between the machine and the world it models.
Done when
Before any code exists, you can state the one thing the user does that the system must never break.
Pair it with Start with The Mom Test for the conversations, then Domain Modeling Made Functional to put the requirement into types.
Specifying so a machine can execute it
14213How to write a specification precise enough that a machine can execute it, then check the result against the system's own behavior.
The artifact and the tool
Start with the video course, not the logic book. Lamport teaches the artifact, and the artifact is the point.
- The TLA+ Video CourseLeslie Lamport
The spine of this stage, and genuinely watchable once you accept that the first two videos are the price of admission.
- Learn TLA+Hillel Wayne
The written on-ramp, better at explaining what a spec is for.
- Logic for ProgrammersHillel Wayne
The prerequisite this stage was missing: logic for working programmers, no math background required.
- AlloyDaniel Jackson
The most immediately satisfying tool here. Write a small model, hit run, and it draws you a counterexample you can click through.
Proof and its falsifier
Proof, model checking, and the current shape of spec-first tooling. Templates are not evidence, so the falsifier sits here too.
The falsifier for any claim that the model has this handled. Agents formally model eleven real system artifacts in TLA+, and the strongest models still fail on conformance for the largest ones.
- Software FoundationsPierce et al.
Proofs about programs, in Coq, free.
Specifications and verification in one language, tutorial assuming no logic background.
Bounded model checking for Rust, the practical industrial entry point.
For the current shape of spec-first tooling. Both are templates, not evidence.
The interface contract for tool use. Specifying an agent's tool surface is this skill applied.
Read as a model of what a legible specification looks like when it is designed to be understood rather than to be clever.
Done when
tlc finds an interleaving bug you predicted before running it, or your model passes conformance against your own service's traces.
Pair it with Watch Lamport first for the artifact, then read Wayne for how specs get adopted. Learn TLA+ alone and you write specs nobody runs.
Reading code you did not write
311How to reach a judgment about code you did not type, which is now most of the code in front of you.
- Crafting InterpretersRobert Nystrom
Build a parser, a resolver, and a bytecode VM. Every indexer, analyzer, and code-graph tool becomes readable afterward, because you have written the thing they are built from. Also the best-written technical book on this list.
- Working Effectively with Legacy CodeMichael Feathers
Cite by title. Sensing and separation, the canonical text on making untested code observable, which is what reading agent output requires.
- The Programmer's BrainFelienne Hermans
How reading code actually works, and why unfamiliar code is slow rather than hard.
Soundness versus completeness, and Tricorder's finding that a noisy check trains developers to ignore the tool.
SCIP, Tree-sitter, and the Language Server Protocol, read as specifications of what a tool can know about code.
Done when
Given a 10k-line repository you have never seen, you can name where a given behavior is decided and point at the tool output that proves it.
Pair it with Read Crafting Interpreters to see how the tools are built, then Legacy Code for the code you actually inherit, which usually has no tests.
Checking the result by measuring it
146433Tools that produce a number instead of an opinion: coverage, mutation score, fuzzing, property tests, and the measurements that say whether the code does what you asked.
The method and the loop
Start with the follow-along material. Testing is the stage where a video course beats a book most clearly, because the loop of write, run, watch it fail is something you learn by doing.
- Web App TestingMiško Hevery
One hour twenty-two minutes, and the best method-first treatment available. The tradeoff between unit, integration, system, and end-to-end tests on scope, speed, and isolation; then refactoring a function so its async call becomes testable; then the anatomy of a test as setup, stimulus, and expectation. Tools appear as illustrations of the method rather than as the subject.
- Gilded Rose refactoring kataEmily Bache
The same method applied until it holds. Take a legacy function with tangled conditionals, pin its behavior with characterization tests, then refactor without changing what it does.
Free material on testing and refactoring as teachable technique rather than tool usage.
Software Engineering at Google chapter 11, free, and the org-scale account of why a test suite decays.
Short practical posts, method over library.
- Obey the Testing GoatHarry Percival
Free. TDD taught by building a real application, with a sense of humor about how badly it goes at first.
- Fuzzing101Antonio Morales
Free. Ten exercises that fuzz real CVEs in real projects. The most satisfying thing on this list, because you find actual bugs.
- The Fuzzing BookAndreas Zeller et al.
Free and complete. The reference version of the same subject.
Property-based testing in TypeScript and Python. Hypothesis shrinks failures into the smallest example, which is the demo that converts people.
- In praise of property-based testingJohn Hughes
What property-based testing found that example-based testing could not.
Stryker and mutmut. The check on the check: coverage says a line ran, mutation score says a test would have noticed.
Browser and dependency testing you can have running in an afternoon.
- Why Programs FailAndreas Zeller
Cite by title. The book-length treatment, in a different register.
What each instrument actually checks
Every item here names a different failure mode. Example-based tests check the cases you thought of. Property-based tests check the ones you did not. Fuzzing checks crash and memory safety at volume. Mutation testing checks the tests.
The reference model for this stage. 155.8 KSLOC of C against 92,053.1 KSLOC of test code, four independent harnesses, 100% branch and MC/DC coverage, and a soak test of about 248.5 million test instances before a release.
The best worked corpus of falsification in the field. Each report names the property it tested and shows the history that broke it.
- Trustworthy Online Controlled ExperimentsKohavi, Tang, Xu
Free companion material. The discipline of deciding in advance what result would change your mind.
For when you cannot randomize. Both free.
Free labs. The failure lens on security, learned by breaking things.
Security as a verifiable checklist rather than a review posture.
- AccelerateForsgren, Humble, Kim
Delivery measured as a rate rather than asserted, and the source of the DORA metrics.
The ledger discipline: a prediction cannot be recorded without naming the command that would refute it, and a verdict cannot be recorded without evidence.
Done when
Deliberately break the code and a test fails, with a mutation score above zero, and a fuzz target runs ten minutes without a new crash.
Pair it with Start with Web App Testing, then add one measurement you do not already have: mutation score, a fuzz target, or a property test.
Operating what shipped
21712What happens after deploy: cost, latency, failure, and the economics that decide what to automate.
Cost, latency, and failure
The expensive-to-check side of the job happens after deploy, in cost, latency, and failure. This is where the economics live, and the free Google books are unusually readable for their length.
- Designing Data-Intensive ApplicationsMartin Kleppmann
The model of correctness under partition, which is the reasoning an agent cannot do for you.
- Distributed SystemsRobert Morris
MIT 6.5840. Lectures, labs, and papers free. Implementing Raft remains the most reliable way to learn why consensus is hard.
- Database SystemsAndy Pavlo
CMU 15-445. Free lectures, and the most entertaining database course in existence. The invariants agents break most often live in the schema and the transaction boundary.
- Operating Systems: Three Easy PiecesArpaci-Dusseau
Free. The substrate the cost model sits on.
The timeout and partial-failure reasoning behind any retry you write. A timeout does not prove the request failed, which is the judgment an agent will not supply.
- Systems PerformanceBrendan Gregg
Measurement before optimization, with the tools to do the measuring, plus the free Linux performance page.
Error budgets and SLOs are the economics this stage covers, and Eliminating Toil is the test for what to automate.
Free self-paced workshops where you design a system under real constraints. The closest thing to a game in this list.
The check on the operation
The check on the operation itself: chaos as an experiment with a hypothesis, supply-chain integrity as a verifiable level, and observability as a discipline rather than a dashboard.
Free. The chapters on testing and deprecation are the practical ones.
Short, and it defines the discipline as an experiment with a hypothesis.
Deterministic simulation testing; the current industrial answer to finding the interleaving bugs a staging environment will not.
Supply-chain integrity as a level you can verify, which matters more when agents produce the artifacts.
- Observability EngineeringMajors, Fong-Jones, Miranda
Cite by title. The publisher page returns 403 to fetches.
Done when
An SLO whose error budget burned, and one incident postmortem recording a hypothesis the evidence falsified.
Pair it with Read DDIA for the theory, then pick one: the SRE books for the human process, or Antithesis and Jepsen for the machine check.
AI engineering, as engineering
22612How to know whether an AI feature works: what the model is doing underneath, and the evals that score it.
The builder's account
What belongs here is how to know whether the thing works. Two poles: the builder's account and the auditor's.
- Neural Networks: Zero to HeroAndrej Karpathy
Build backpropagation from scratch, then a tokenizer, then a small GPT. The most watchable serious ML material available, and it removes the mystery from the thing you are prompting.
- Neural networks series3Blue1Brown
The animated version, if you want the intuition before the code.
- The Hard Parts of Neural NetworksWill Sentance
The same ground in the lecture register, listed in full in stage 1.
- Understanding Deep LearningSimon Prince
Free. The reference version of the same ground.
- AI EngineeringChip Huyen
Cite by title. The publisher page returns 403 to fetches, so her blog is the free entry point.
The auditor's account
Evals are the checking track for this stage, and the skeptical empirical lens is what keeps the builder's account honest.
- Building effective agentsAnthropic
The clearest short account of what an agent is and when not to build one.
The mechanics behind context rot.
- What We've Learned From a Year of Building with LLMsYan, Bischof, et al.
The most honest operational account available free, with a blog worth following.
- AI Evals for Engineers and ProductHamel Husain, Shreya Shankar
A paid cohort, with free entry points at evals.info and Hamel's blog. Evals are the checking track for this stage.
- AI Snake OilArvind Narayanan, Sayash Kapoor
The skeptical empirical lens on the same claims.
Prompt injection is the standing one. The failure lens on agent security, learned by breaking things.
- Simon Willison's blogSimon Willison
The running primary record on prompt injection and agent security, written plainly and updated faster than any course.
- Exploring Generative AIMartin Fowler and colleagues
Field notes on what teams actually hit when they build with these models.
Done when
An eval suite where a prompt change moved the score in the direction you predicted before running it.
Pair it with Watch Karpathy to see what the model is doing, then read the eval material, because a prompt you cannot score is a guess.
Judgment under uncertainty
41Acting on a forecast, calibrating a prediction, and knowing when a measurement is worth its cost. Predicting well is trainable.
Free interactive tools that calibrate your judgment by making you commit to answers first. The most fun way into this stage.
- Thinking in BetsAnnie Duke
Separating luck from decision quality.
- SuperforecastingPhilip Tetlock, Dan Gardner
Calibration, and how accuracy is actually scored.
- The Scout MindsetJulia Galef
The motivation to notice you were wrong, which no tool supplies.
- Trustworthy Online Controlled ExperimentsKohavi, Tang, Xu
The industrial version of the same discipline.
Done when
Your recorded predictions beat chance at a stated horizon, over at least twenty of them.
Pair it with Use Clearer Thinking to start committing to answers, then keep a written record of predictions and score yourself against it.
The primary record
26The papers and talks behind everything above, for when you want the source rather than the summary.
The primary sources behind every claim above, and the reason this stage sits last: the list earns its argument before it cites it.
- The programmer and the coderGrace Hopper
1954, on the programmer and coder split, and why the coder's job would be the first replaced by the computer itself.
The FORTRAN preliminary report's claim that it should virtually eliminate coding and debugging, reprinted with commentary in Backus's 1978 retrospective.
- The coder's historyNathan Ensmenger
How FORTRAN and COBOL had the unintended effect of elevating their status rather than eliminating the role.
- No Silver BulletFred Brooks
1986. Essential versus accidental difficulty, the vocabulary this whole list depends on.
- What Is Software Design?Jack Reeves
1992. The objection that coding is design, which rules out the easy version of the argument.
- Go To Statement Considered HarmfulEdsger Dijkstra
EWD215, 1968, on why legibility is the point of an abstraction.
Talks on the same papers, in a conversational register, when the PDF is too dry.
Interviews with the people who wrote the systems. The best commute-length source here.
Done when
You can name which claim in your design came from which paper.
Pair it with Read the papers for the claims, and use Papers We Love or SE Radio when a primary source is too dry to finish.