Read first
How to use this plan
The phases are ordered by dependency, not by importance. C before the machine, the machine before the OS, the OS (on a small teaching kernel) before Linux, C++ and compilers before browsers. Each phase has a core list to do in order, an optional go deeper list, and exit criteria: concrete things you can do or have built. Move on when you meet the exit criteria, not when you have finished the list.
A working week
- Two lab sessions of 2–3 hours each. Type every line yourself; no copying solutions.
- One reading or lecture session, taken before the lab that needs it.
- One source-reading session: open a real codebase in a debugger and trace one path end to end.
- Thirty minutes to write the week's log entry: what you built, what broke, what you now understand.
Minimum kit
- A Linux machine or VM (Ubuntu/Debian/Fedora). WSL2 on Windows works for everything except some driver labs.
gcc,clang,gdb,make,cmake,qemu-system-riscv64andqemu-system-x86_64,git,valgrind,perf.- Optional from Phase 3: a Raspberry Pi or a board supported by the course you pick, plus a USB-serial adapter.
- A second monitor or a wide terminal. You will keep source, debugger and notes open at once.
Free fully open Free to audit free content, paid certificate Paid optional purchase Hardware needs a board
Entry points
Where to start, by background
New to programming
Start at Phase 0 and do all of it, including CS50. Budget the full 1,500 hours plus slack. Expect the first three months to feel slow; the curve bends after CS:APP.
Application developer (Python, JS, Java, Go)
Phase 0 without CS50: Beej's C, Modern C, Missing Semester, GDB. Then everything from Phase 1. C will feel restrictive for about a month; that is the point.
Knows C/C++, never did systems work
Skip to Phase 1. Use the CS:APP Bomb Lab and Malloc Lab as a diagnostic: if both are comfortable, start at Phase 2.
Returning after years away from kernel or driver work
Two to four weeks of recalibration: Missing Semester (for the tooling that changed), the CS:APP Attack and Malloc labs, then straight into the MIT 6.1810 xv6 labs in Phase 3. From there branch to Phase 4, 6 or 7 depending on the goal. What is new since roughly 2012: RISC-V as the teaching ISA, Rust in the kernel, eBPF, io_uring, Clang sanitizers, C++17/20, and multi-process, GPU-composited browser architectures.
Embedded or firmware engineer
Skip Phases 0–2. Do Phase 3 through Stanford CS 140E (bare-metal on a Pi), then Phase 4 with the Bootlin kernel labs, which target the boards you already know.
Only interested in browsers
You still need Phases 0, 1, 2, 5 and 6 — browsers are C++ programs built on a compiler-shaped core (a JS engine) and a renderer that cares about caches and threads. Phases 3–4 can be skimmed: read OSTEP, skip the kernel labs.
Phase 0est. 60–100 h
Tooling and C
Goal. Write, build, debug and profile C programs on Linux without friction, so that none of the later labs are slowed down by the toolchain. Everything else in this plan assumes this phase.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| CS50xHarvard | Course + problem sets | Weeks 1–5 are C: memory, pointers, data structures, with autograded problem sets. Skip if you already write C comfortably. | Free |
| Beej's Guide to C ProgrammingBrian "Beej" Hall | Free book | Plain-spoken, complete C reference. Read it once, keep it open for the rest of the plan. | Free |
| Modern CJens Gustedt (Inria) | Free book (PDF) | C as written today (C17/C23): const-correctness, restrict, atomics, threads, undefined behaviour. Read after Beej. | Free |
| The Missing Semester of Your CS EducationMIT | Lectures + exercises | Shell, scripting, editors, git, debugging and profiling, build systems. The tooling every later phase assumes you have. | Free |
| Beej's Quick Guide to GDB and the GDB manualBeej / GNU | Guide + reference | Breakpoints, watchpoints, backtraces, TUI mode, remote debugging. You will live in GDB from Phase 1 onward; learn it before you need it. | Free |
| Valgrind quick startValgrind project | Guide | Find leaks and invalid reads in your own C before a lab's test driver does. | Free |
| GNU Make manual and the CMake tutorialGNU / Kitware | Reference + tutorial | Make for course labs and the kernel; CMake for the C++ projects in Phases 5–7. Read the first three chapters of each, then learn by fixing build failures. | Free |
| Compiler ExplorerMatt Godbolt | Tool | Paste C, read the assembly. Use it weekly; it is the fastest way to build machine intuition before Phase 1. | Free |
| Exercism C trackExercism | Practice + mentors | Small exercises with volunteer mentor feedback. Good for keeping daily momentum between bigger labs. | Free |
Go deeper (optional)
- Introduction to Linux (LFS101), Linux Foundation — if Linux itself is new: filesystem layout, users, processes, packaging.
- Project Based Learning — curated "build X in C" tutorials to pick one small project from before Phase 1.
Exit criteria
- You can write a 300-line C program with a Makefile, debug a segfault in GDB, and clear it in Valgrind without looking anything up.
- You can explain, from memory, what a pointer to a pointer is, why
sizeofdiffers fromstrlen, and what undefined behaviour means. - Your study repository exists, is public, and has its first log entry.
Phase 1est. 150–250 h
The machine underneath
Goal. Understand what the hardware does with your code: integer and float representation, assembly, the stack, caches, virtual memory, linking, and exceptions. One course is the hinge of this entire plan, and it is CS:APP.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| 15-213 Introduction to Computer Systems (CS:APP)Carnegie Mellon | Course + lecture videos | Data representation, x86-64 assembly, the memory hierarchy, linking, exceptions and processes, virtual memory, system I/O, networking, concurrency. The schedule page links lecture videos; the textbook is paid but optional if you pair lectures with Dive into Systems. | Free |
| CS:APP self-study labsBryant & O'Hallaron | Labs with drivers | Do Data, Bomb, Attack, Cache, Shell, Malloc and Proxy labs in that order. Each ships with a local test driver, so you can grade yourself. | Free |
| Dive into SystemsMatthews, Newhall, Webb | Free textbook | A free companion or substitute for the CS:APP book: C, x86-64/ARM64/RISC-V assembly, caches, the OS, parallelism. Read the matching chapter before each lab. | Free |
| Nand2Tetris (Coursera Part 1)Nisan & Schocken | Course + simulator projects | Build a computer from NAND gates to an assembler in simulation. Do Part 1 if you have never seen hardware; Part 2 (VM, compiler, OS) if you plan to skip Phase 6. | Free to audit |
| CS 61C Great Ideas in Computer ArchitectureUC Berkeley | Course + public projects | C, RISC-V assembly, CPU pipelining, caches, virtual memory, parallelism. The RISC-V grounding pays off directly in the xv6 labs in Phase 3. | Free |
| What Every Programmer Should Know About MemoryUlrich Drepper | Paper (PDF) | The memory-hierarchy paper everyone cites. Read parts 1–6 after the Cache Lab; the rest after Phase 5. | Free |
Go deeper (optional)
- Digital Design and Computer Architecture and Computer Architecture, Onur Mutlu, ETH Zürich — full lecture videos; the most thorough free architecture sequence available.
- Ben Eater — breadboard 8-bit CPU and 6502 videos. The quickest way to feel what a bus, a clock and a register are. Hardware optional.
- CSE 351 The Hardware/Software Interface, University of Washington — a gentler CS:APP-based course with public labs if 15-213 feels too steep.
- CS 61 Systems Programming and Machine Organization, Harvard — CS:APP material with modern C++ and excellent problem sets.
Exit criteria
- Bomb Lab and Attack Lab defused and exploited; Malloc Lab allocator scores in the 90s on the driver; Shell Lab passes all traces.
- You can read a function's compiled assembly and reconstruct its control flow and stack frame.
- You can explain why a row-major loop over a 2D array is faster than column-major, with approximate numbers for L1/L2/L3/DRAM latency.
Phase 2est. 120–180 h
Unix systems programming
Goal. Use the operating system from user space fluently — processes, signals, files, pipes, threads, sockets — before you try to build one. This is also where you start Phase 5 (C++) in parallel if you have time.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| CS 107 Computer Organization and SystemsStanford | Course + assignments | C strings and pointers, memory, x86-64, a heap allocator. Lecture videos and assignments are public. Overlaps CS:APP; use it to consolidate, or skip to CS 110 if Phase 1 went well. | Free |
| CS 110 Principles of Computer SystemsStanford | Course + assignments | Filesystems, processes, signals, threads, condition variables, networking and servers. The Unix-API course. | Free |
| CS 341 System Programming coursebookUniversity of Illinois | Free online book | fork/exec, pipes, signals, pthreads, synchronisation, virtual memory, networking, with a deliberate "how this breaks" angle and exercises. | Free |
| Linux man-pagesMichael Kerrisk | Reference | The primary source for every syscall and libc function. Learn to read section 2 and 3 pages before reaching for a search engine. | Free |
| Beej's Guide to Network Programming and Beej's Guide to Unix IPCBeej | Free books | Sockets (TCP/UDP, select/poll, IPv6) and IPC (pipes, FIFOs, signals, shared memory, semaphores, Unix domain sockets). Write a chat server and a multi-process pipeline. | Free |
| POSIX Threads ProgrammingLawrence Livermore National Laboratory | Tutorial | Concise pthreads tutorial: mutexes, condition variables, and the classic mistakes. Pair with the concurrency chapters of OSTEP (Phase 3). | Free |
| CS 144 Introduction to Computer NetworkingStanford | Course + labs with tests | Build a working TCP implementation in C++ (the "Minnow" labs) that exchanges data with the real internet, then an IP router and a network interface. Tests are included; this is the first big project in the plan. | Free |
Go deeper (optional)
- The Linux Programming Interface, Michael Kerrisk — the definitive Linux/POSIX API reference. Paid, and the one systems book worth buying first.
- Jacob Sorber on YouTube — short, practical C and systems videos (sockets, threads, memory, debugging) for when a concept has not clicked.
- pwn.college (Intro to Cybersecurity and Program Security) — the best way to learn the Linux process model and memory layout is to exploit it; the early modules are a systems course in disguise.
Exit criteria
- Your TCP implementation passes the CS 144 test suite and can fetch a web page over the real network.
- You have written a shell that handles pipes, redirection, background jobs and signals correctly.
- You can explain what happens between typing
./a.outandmain()running: fork, exec, the dynamic loader, and the first page fault.
Phase 3est. 200–300 h
Operating systems: build xv6, then your own
Goal. Implement the core mechanisms of an OS yourself — system calls, page tables, traps, scheduling, locks, a file system, a network driver — inside a kernel small enough to understand completely. Do this on a teaching kernel first; going straight to Linux is the most common way to stall.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| Operating Systems: Three Easy Pieces (OSTEP) and the OSTEP projectsArpaci-Dusseau, University of Wisconsin | Free book + projects with tests | Virtualisation, concurrency, persistence. Read each chapter right before the xv6 lab that needs it; the projects repo adds xv6 and user-space projects with test scripts. | Free |
| 6.1810 Operating System Engineering (formerly 6.828 / 6.S081)MIT PDOS | Course + labs with local grader | The best self-study OS labs in existence, on xv6-riscv: utilities, system calls, page tables, traps, copy-on-write fork, multithreading, a network driver, lock tuning, a file system, mmap. make grade checks your work locally. The lecture videos from recent years are on the schedule page. |
Free |
| xv6-riscv source and the xv6 bookMIT PDOS | Source + book | Read the book chapter by chapter with the source open and GDB attached to QEMU. xv6 is about 6,000 lines; understand all of it. | Free |
| CS 162 Operating Systems and Systems ProgrammingUC Berkeley | Course + Pintos projects | Lectures, discussion sections and the Pintos projects (threads, user programs, file systems) for a second, more design-oriented pass. The autograder is for enrolled students; rely on the test suites in the project repository. | Free |
| Linux Insides0xAX | Free book | A book-length walkthrough of how Linux boots and initialises on x86-64. The bridge from xv6 to the Linux kernel in Phase 4. | Free |
Go deeper (optional) — a second kernel, from zero
- CS 140E Embedded Operating Systems, Dawson Engler, Stanford — write everything from the bootloader up in C on a Raspberry Pi: UART, GPIO, interrupts, threads, virtual memory, a file system. Complete class materials are in the repository; check its hardware list before buying a board. Hardware
- CS 3210 Design of Operating Systems, Georgia Tech — the same idea in Rust on a Raspberry Pi 3. Hardware
- Writing an OS in Rust, Philipp Oppermann — a freestanding x86-64 kernel in Rust: interrupts, paging, heap, async tasks. No hardware needed.
- The Little Book About OS Development — a short x86 kernel from scratch: GRUB, interrupts, paging, user mode.
- Learning operating system development using Linux kernel and Raspberry Pi and Cambridge's Baking Pi — bare-metal ARM step by step, with each lesson compared to how Linux does it.
- 15-410 Operating System Design and Implementation, CMU — the famously heavy x86 kernel project; use its documents if you want a third design pass.
- OSDev Wiki — the reference encyclopedia for bare-metal work (boot, GDT/IDT, paging, drivers, cross-compilers). A reference, not a tutorial.
Exit criteria
- All 6.1810 labs pass
make grade, including copy-on-write fork, the network driver and mmap. - You can draw, from memory, what happens on a timer interrupt in xv6: trap entry, saving registers, the scheduler, context switch, trap return.
- You can explain page-table walks, TLB behaviour and the difference between a page fault and a segfault to someone who has only used Python.
Phase 4est. 200–400 h
The Linux kernel and device drivers
Goal. Build, modify, debug and extend the real Linux kernel; write character, platform and network drivers; and get a patch accepted upstream. The resources are ordered from "official on-ramp" to "deep reference", with the community steps at the end.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| A Beginner's Guide to Linux Kernel Development (LFD103)Linux Foundation | Course | Configuring, building, installing and debugging a kernel, bisecting regressions, and the mailing-list workflow, taught by a kernel maintainer. The official on-ramp; about a week of evenings. | Free |
| The Linux Kernel Module Programming Guidesysprog21 (maintained fork) | Free book | Write modules against a current kernel: character devices, procfs and sysfs, ioctl, interrupts, deferred work, scheduling, locking. Kept up to date, unlike most module tutorials. | Free |
| Linux Kernel Teaching (Linux Kernel Labs)University Politehnica of Bucharest | Lectures + labs in a prepared VM | The closest thing to a full kernel course with labs: modules, kernel API, character devices, I/O access and interrupts, deferred work, memory mapping, block devices, networking, file systems, virtualisation. Each lab ships in a QEMU image. | Free |
| Linux Device Drivers, 3rd edition (LDD3)Corbet, Rubini, Kroah-Hartman (O'Reilly, free) | Free book | Still the clearest mental model of driver structure: char, block and network drivers, concurrency, memory mapping, DMA, interrupt handling. The APIs date from kernel 2.6, so read it with the current kernel docs open and port its examples. | Free |
| Linux kernel and driver development training and Embedded Linux system developmentBootlin | Professional slides + lab books | Commercial training materials released free. The kernel course builds real I2C, serial and DMA drivers on a small ARM board; the embedded course covers bootloaders, kernel configuration, root filesystems and Buildroot. Parts adapt to QEMU. Hardware optional. | Free |
| The Linux Kernel documentation: Driver API guide, development process, submitting patcheskernel.org | Reference | The authoritative source. Read the driver model, device tree and coding-style documents before writing a driver, and the process documents before sending anything. | Free |
| Elixir cross-referencerBootlin | Tool | Browse any kernel version with symbol cross-references. Faster than grep for learning a subsystem; use it alongside cscope or clangd locally. |
Free |
| KernelNewbies: First Kernel Patch and KernelNewbiesCommunity | Guide + community | A step-by-step path to a first accepted patch (staging-driver cleanups, checkpatch fixes, documentation), plus the IRC/mailing-list etiquette that decides whether anyone replies. | Free |
| LWN.netLWN | Weekly publication | Read the Kernel page every week. It is how you learn what the project is actually doing and why, and it is the best-written technical journalism in the field. Current-week articles are subscriber-only; everything becomes free after a week. | Free |
Go deeper (optional)
- Understanding the Linux Virtual Memory Manager, Mel Gorman — the deep dive on the VM subsystem; the kernel version is old, the concepts are not.
- eBPF — running sandboxed programs inside the kernel for tracing, networking and security; the modern entry point into kernel work for many people, with tutorials and labs.
- Rust for Linux — documentation and status for Rust in the kernel, including how to write a Rust driver.
- Yocto Project and OpenEmbedded training, Bootlin — if your target is embedded products rather than the kernel itself.
- Modern Embedded Systems Programming, Miro Samek, and the Zephyr and FreeRTOS docs — the microcontroller/RTOS side of driver work, for when there is no Linux underneath.
- Windows Driver Kit documentation — if you need Windows: the WDF driver model, samples, and WinDbg.
The community step
Mentorships turn this phase from solo study into supervised work. The Linux Foundation mentorship programmes, applied for through the LFX Mentorship portal, run 12-week paid Linux Kernel terms (bug fixing, subsystem work) with maintainers as mentors, three times a year. The application tasks — build and upgrade a kernel, run fuzzers, submit a documentation fix — double as a checklist for this phase. Outreachy also runs kernel internships for under-represented groups, and Google Summer of Code is open to new contributors of any age.
Exit criteria
- You have built, installed and booted your own kernel, bisected at least one regression, and can debug the kernel with GDB attached to QEMU.
- You have written a character driver with ioctl and interrupt handling, and a platform driver bound through device tree, and tested them in QEMU or on a board.
- At least one patch of yours has been merged upstream — a cleanup or documentation fix counts. You have read the review comments on someone else's rejected patch and understood why.
Phase 5est. 100–200 h · parallel track from Phase 2
Modern C++ for systems
Goal. Write the C++ that large systems codebases (Chromium, WebKit, LLVM, databases, game engines) expect: RAII, move semantics, templates, the standard library, concurrency, sanitizers, CMake. This track can run alongside Phases 2–4; finish it before Phase 7.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| learncpp.comAlex and Nascardriver | Free tutorial (book-length) | The most complete free C++ course. Work through it end to end once, then use it as a reference. | Free |
| Modern C++ ProgrammingFederico Busato (NVIDIA) | University course as slides | A complete course from basics through templates, the STL, concurrency, performance and tooling, updated for C++20/23. Use it to fill gaps after learncpp. | Free |
| hacking C++André Müller | Visual cheat sheets + articles | Concise, visual explanations of modern C++ and the standard library. Print the cheat sheets. | Free |
| CppCon (start with the Back to Basics playlists) and C++ WeeklyCppCon / Jason Turner | Conference talks / short videos | Back to Basics covers RAII, move semantics, templates, concurrency and API design the way practitioners use them. C++ Weekly is ten minutes a week on idioms and pitfalls. | Free |
| C++ Core Guidelines, Google C++ Style Guide, Abseil Tip of the WeekStroustrup & Sutter / Google | Guidelines | What real codebases enforce. Read the Core Guidelines sections on resource management and concurrency; read the Google guide before touching Chromium, which uses a derivative of it. | Free |
| Sanitizers (ASan, UBSan, TSan, MSan) and An Introduction to Modern CMakeGoogle / Henry Schreiner | Tools + guide | Turn sanitizers on in every project from now on; learn CMake properly once so it never blocks you again. | Free |
| 15-445/645 Database Systems (BusTub project)Carnegie Mellon | Course + large C++ project with tests | The best large-scale modern-C++ project course: a buffer pool, hash index, query executors and concurrency control inside a real codebase with a test suite. Recent terms have offered a public Gradescope to non-CMU students; check the current term's FAQ. | Free |
Go deeper (optional)
- cppreference — the standard-library reference; learn to read it instead of tutorials.
- 6.172 Performance Engineering of Software Systems, MIT OpenCourseWare — Bentley's rules, cache-aware algorithms, multicore parallelism, profiling; with homeworks and projects. Listed again under Phase 8.
- The Cherno's C++ series — an informal video alternative to learncpp if you learn better by watching.
Exit criteria
- Your BusTub passes the public tests for at least the buffer pool and index projects, with sanitizers clean.
- You can explain the rule of five, when a move happens and when it does not, what a dangling
string_viewis, and whystd::shared_ptris not thread-safe in the way people assume. - You have read and understood a 5,000-line C++ codebase you did not write, using only CMake, the debugger and the code.
Phase 6est. 100–200 h
Compilers, linkers and runtimes
Goal. Build an interpreter and a bytecode VM, then a C compiler in stages, and understand what the toolchain does between your source and a running process. A browser is, at its core, a compiler-shaped program (a JavaScript engine) wrapped in a renderer, so this phase comes right before browsers.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| Write Your Own Virtual MachineJustin Meiners & Ryan Pendleton | Tutorial | An LC-3 virtual machine in C in one evening. A warm-up that makes "fetch, decode, execute" concrete. | Free |
| Crafting InterpretersRobert Nystrom | Free book (complete code) | Build a tree-walking interpreter, then a bytecode compiler and VM with a garbage collector in C. The single best on-ramp to runtimes and to how a JavaScript engine thinks. | Free |
| Writing a C Compiler (blog series)Nora Sandler | Tutorial series | A C compiler in small, testable stages: lexer, parser, x86-64 code generation, then operators, variables, functions. The 2024 book version is much expanded. Paid for the book only. | Free |
| chibiccRui Ueyama | Source, written to be read | A small C compiler developed in readable commits, each adding one feature. Read it after Sandler's series to see how far "small" can go; it compiles real programs. | Free |
| Linkers (20-part series) and Linkers and LoadersIan Lance Taylor / John Levine | Blog series + free book | How ELF linking works — symbols, relocations, shared libraries, lazy binding — from the author of gold, and the classic text on object files and loaders. | Free |
| LLVM Kaleidoscope tutorialLLVM project | Tutorial | A language front-end on LLVM: IR generation, JIT, optimisation passes, debug info. The production way to build a backend. | Free |
Go deeper (optional)
- CS 143 Compilers, Stanford — the theory (lexing, parsing, semantic analysis, optimisation, code generation) with assignments that build a compiler for COOL.
- CS 6120 Advanced Compilers: the self-guided course, Adrian Sampson, Cornell — SSA, dataflow, LLVM passes, JITs, garbage collection, with video lectures and tasks designed for self-study.
- An Incremental Approach to Compiler Construction, Abdulaziz Ghuloum — the paper behind the "one tiny feature at a time" method used by Sandler and chibicc.
- V8 blog and JavaScript engine fundamentals: shapes and inline caches — how a production JS engine works (hidden classes, inline caches, tiered compilation). Read once you have built your own bytecode VM.
Exit criteria
- Your bytecode VM runs the full Lox test suite from Crafting Interpreters, including closures and the garbage collector.
- Your C compiler handles functions, loops, pointers and arrays, and its output links and runs against glibc.
- You can explain, with
readelfandobjdumpoutput in front of you, how a call into a shared library is resolved at runtime.
Phase 7est. 150–300 h
Browser engines
Goal. Build a small browser yourself, then read and contribute to a real engine. Browsers are the largest codebases in this plan — Chromium is tens of millions of lines — so the order is strict: concepts, then a toy you built, then the smallest real engine, then the big ones.
Core — do these in order
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| How browsers work and Inside look at modern web browser (4 parts)Tali Garsiel & Paul Irish / Mariko Kosaka | Articles | The architecture tour: parsing, DOM and CSSOM, layout, paint, compositing, and how Chrome splits work across processes and threads. Two evenings of reading before you write anything. | Free |
| Web Browser EngineeringPavel Panchekha & Chris Harrelson | Free book; build-along | Build a working browser in Python, chapter by chapter: HTTP, HTML and CSS parsing, layout, rendering, forms, JavaScript via an embedded engine, security, accelerated graphics. This is the centre of the phase. Then re-implement the layout and paint chapters in C++ or Rust. | Free |
| Let's build a browser engine! (7 parts)Matt Brubeck (Servo) | Tutorial series | A toy layout engine in Rust: DOM, CSS parsing, style computation, the box model, painting. Short, and a good template for your C++/Rust rewrite. | Free |
| Ladybird (source) and Andreas Kling's browser-hacking videosLadybird Browser Initiative | Real engine + recorded development sessions | An independent engine in C++ that is still small enough to read, with hours of recorded sessions showing how features are implemented from the spec. The best first real engine, and an active on-ramp for new contributors. | Free |
| HTML Standard, CSS Snapshot, ECMA-262WHATWG / W3C / TC39 | Specifications | Browser engineering is spec implementation. Learn to read the HTML parsing algorithm and a CSS module end to end; the Ladybird videos show how the spec text maps to code. | Free |
| Chromium design documents, multi-process architecture, getting around the source, in-tree docsChromium project | Documentation | How a production browser is organised: process model, sandboxing, IPC, Blink, the compositor. Read the documents before opening the code. | Free |
| Life of a Pixel and RenderingNGSteve Kobes / Chrome team | Slides (with video) + articles | Chromium's rendering pipeline from HTML to pixels with pointers into the classes, and the current architecture (composite-after-paint, property trees, Skia, the GPU process). | Free |
| Contributing to Chromium, Contributing to Firefox + Codetribute, WebKit Getting StartedChromium / Mozilla / WebKit | Contributor guides | The build-and-contribute paths for the three big engines. Codetribute lists mentored good-first bugs with a named mentor, which is the easiest way into Firefox. | Free |
Go deeper (optional)
- Servo and The Servo Book — the Rust engine; the book covers architecture, building and contributing. The natural home for the Rust track.
- Firefox Source Docs and WebKit documentation — internals documentation for Gecko and WebKit.
- How cc works — Chromium's compositor, explained by its maintainers.
- Skia — the 2D graphics library under Chrome, Android and Flutter.
- Chromium security — sandboxing, site isolation and the bug classes that drive browser architecture.
Exit criteria
- Your browser from Web Browser Engineering renders real pages with CSS, handles forms, and runs scripts; your C++ or Rust rewrite of layout and paint matches it on a test corpus you wrote.
- You have built Ladybird or Servo from source, traced one CSS property from the parser to pixels in the debugger, and had at least one pull request merged.
- You can explain to a web developer why the main thread, the compositor thread and the GPU process exist, and what moves between them.
Phase 8 · optionalest. 100–300 h per track
Specialise
Goal. Pick one track and go deep. Each is a direction the industry pays for, and each reuses everything above.
| Track | Format | Resources and what you build | Cost |
|---|---|---|---|
| Performance engineering | Course + references | MIT 6.172 Performance Engineering (OCW, with projects) · Brendan Gregg's Linux Performance · perf wiki · Agner Fog's optimisation manuals · Computer, Enhance! by Casey Muratori (Paid). Build: a profiler-driven optimisation of your own Phase 5 code with before/after numbers. | Free |
| Parallel and GPU computing | Courses + lecture series | Stanford CS 149 Parallel Computing · CMU 15-418 Parallel Computer Architecture and Programming · GPU MODE lectures (CUDA kernels, profiling, the PMPP book chapters). Build: a CUDA or SIMD implementation of a kernel you first wrote scalar, with a roofline analysis. | Free |
| Systems security | Hands-on platform + course | pwn.college (memory corruption, kernel security, sandboxing, with live challenges) · MIT 6.858 Computer Systems Security · AFL++ and libFuzzer. Build: a fuzzing harness for a parser you wrote in Phase 6 or 7, and fix what it finds. | Free |
| Distributed systems | Course + labs with tests | MIT 6.5840 (6.824) Distributed Systems — Raft, a fault-tolerant key-value store, sharding, in Go, with a test suite. Build: the full lab sequence; then port the Raft core to C++ or Rust. | Free |
| Bare-metal and platform layers | Video archive + manuals | Handmade Hero (a game and its platform layer written from scratch in C, on camera) · Intel Software Developer Manuals · Arm Architecture Reference Manual. Build: a windowing, input and audio platform layer with no libraries. | Free |
Cross-cutting track
Rust, alongside C and C++
Rust is now a first-class systems language in the Linux kernel, in Android, in Servo and in much new infrastructure. It does not replace C in this plan — every course above is in C or C++ — but learning it in parallel from Phase 3 onward makes you more employable and, more usefully, teaches ownership and aliasing rules that make you a better C programmer.
| Resource | Format | Use it for | Cost |
|---|---|---|---|
| The Rust Programming Language and RustlingsRust project | Book + exercises | The official book and the small exercises that go with it. Two to three weeks of evenings. | Free |
| Comprehensive RustGoogle Android team | Course (4 days + deep dives) | Google's internal Rust course, including the bare-metal and concurrency deep dives and an Android/C interop module. | Free |
| Rust Atomics and LocksMara Bos (free online edition) | Book | The best short treatment of memory ordering, atomics, spinlocks and condition variables in any language. Read after the OSTEP concurrency chapters. | Free |
| The Embedded Rust Book, Writing an OS in Rust, Rust for LinuxRust Embedded WG / Oppermann / kernel community | Books + docs | Rust on microcontrollers, a Rust kernel from scratch, and Rust inside Linux — the three systems directions, in the order to try them. | Free |
Without a teacher
Where the feedback comes from
The reason self-teaching fails is not lack of content; it is lack of correction. Each phase above was chosen so that something other than you tells you whether you are right.
Automated
- CS:APP labs ship test drivers; the Malloc Lab gives a numeric score.
- MIT 6.1810:
make graderuns the full lab test suite locally. - CS 144, OSTEP projects, Crafting Interpreters and 15-445 ship test suites; 15-445 has offered a public autograder.
- Sanitizers, Valgrind and fuzzers tell you about bugs the tests did not.
Human
- Kernel mailing lists review every patch in public. Read reviews of others' patches before sending yours.
- Ladybird, Servo and Mozilla (via Codetribute) review pull requests from newcomers and say what to fix.
- Exercism mentors review small C solutions.
- Writing up each phase publicly invites correction; the write-up is also the thing a future employer reads.
Project hubs and communities
- Build your own X — curated tutorials for building shells, databases, emulators, network stacks and more from scratch; good for choosing side projects between phases.
- CodeCrafters — guided "build your own Redis / git / HTTP server / interpreter" challenges with automated stage tests in C, C++ or Rust. Paid with a free tier.
- Teach Yourself Computer Science and OSSU Computer Science — broader self-study curricula if you want the rest of a CS degree around this plan.
- KernelNewbies and LWN — where kernel learners and kernel developers actually talk.
Portfolio
Six capstones that prove it
Each comes out of a phase above. Together they are the evidence that replaces a transcript. Aim for four.
1. An extended xv6
Copy-on-write fork, lazy allocation, mmap and a working E1000 network driver, with the 6.1810 grader passing. Phase 3.
2. A TCP/IP stack
A user-space TCP implementation and IP router passing the CS 144 tests and talking to real hosts. Phase 2.
3. A Linux driver and an upstream patch
A character or platform driver for a QEMU device or real board, plus at least one patch merged into mainline. Phase 4.
4. A compiler or a VM
A C compiler for a useful subset that links against glibc, or a bytecode VM with a garbage collector passing a test suite. Phase 6.
5. A toy browser and a merged engine PR
Your browser.engineering build rewritten in C++ or Rust, and a pull request merged into Ladybird or Servo. Phase 7.
6. A storage engine
BusTub with buffer pool, index, executors and concurrency control passing the public tests, sanitizers clean. Phase 5.
Time
How long it takes
Midpoint estimates, assuming no weeks off. Add about 15% for life. The hours are for the core path (Phases 0–7); Phase 8 and the Rust track are on top.
| Starting point | Core hours | At 10 h/week · 15 h/week · 20 h/week | |
|---|---|---|---|
| Full path from Phase 0 | ≈1,500 h | about 2.9 years · 1.9 years · 1.4 years | |
| Already fluent in C/C++, from Phase 1 | ≈1,400 h | about 2.7 years · 1.8 years · 1.4 years | |
| Returning systems engineer, refresh + Phases 3–7 | ≈1,100 h | about 2.1 years · 1.4 years · 1.1 years | |
| One target only (kernel or browsers), with the prerequisite phases | ≈800–1,000 h | about 1.7 years · 1.2 years · 0.9 years |
These are realistic numbers for reaching "can do the job", not "has heard of it". A university student covers Phases 1–3 and 6 in roughly four semester courses, which is about 600 hours including lectures; the plan's estimates are in line with that, with the kernel and browser phases added on top.
Known failure modes
Pitfalls
- Lectures without labs. Watching all of 15-213 and building nothing leaves you where you started. If a week has no lab time, it was not a study week.
- Starting with the Linux kernel. It is thirty million lines. Finish xv6 first; Linux then looks like a very large xv6, which is roughly true.
- Starting with Chromium. Same problem, plus a multi-hour build. Toy browser first, then Ladybird, then the big engines.
- Reading solutions. Every lab in this plan has solutions online. Reading one before struggling for at least a few hours removes the whole value of the lab.
- Skipping the debugger. Systems programmers read state, not just code. If you are adding print statements to a kernel, you have skipped Phase 0.
- Language tourism. C, C++ and Rust are enough. Adding Zig, Go and Nim in parallel is a way of avoiding the hard parts of each.
- Private progress. Work nobody can see does not count as experience to anyone else, and it cannot be corrected.
- Hardware rabbit holes. Every bare-metal course in Phase 3 is optional. QEMU is enough to finish the core path.