Course Map — Debugging From First Principles
Most engineers learn debugging by accident. They pick up a few tools, copy a few commands from a colleague, and spend the rest of their career guessing a little faster. This track teaches it on purpose.
The point is not complexity. The point is that debugging has a method, a vocabulary, and a map of where evidence lives — and once you have all three, an unfamiliar bug stops being scary. You know what to ask, where to look, and what each answer rules out.
The One Idea
Debugging is shrinking the space of possible causes using evidence.
Every technique in this track — reading a stack trace, checking a status code, bisecting commits, reading a trace waterfall — is a way to cut the space of "things that could be wrong" in half, cheaply, without guessing. If an action does not shrink that space, it is not debugging. It is hoping.
How the Track Is Built
The track goes from the ground up. Each part assumes only the parts before it.
Part 1 — Foundations. The method and the language. What every error, code and status is actually telling you. After this part, no error message is noise.
Part 2 — Instruments. One chapter per layer a request passes through: the browser, the network, the server process, the database, and production observability. Each chapter answers one question: what can this layer tell me that nothing else can?
Part 3 — The Casebook. Real investigations, start to finish — many of them playable: you choose the next check and see what it would have shown. A symptom, the first five minutes, ranked hypotheses, the evidence that kills or confirms each one, the root cause, the fix, and how to prevent it.
Part 4 — After the Bug. Incidents, postmortems, and how to tell a debugging story in an interview.
Chapter Map
| # | Chapter | What you can do after it | Status |
|---|---|---|---|
| 1 | The Debugging Method | Run a disciplined investigation; name every step and every kind of bug | written |
| 2 | Reading Errors and Stack Traces | Read any JS/Node error and know exactly where to look next | written |
| 3 | Error Codes Below Your App | Decode ECONNRESET, exit code 137, SQLSTATE 23505, TLS errors | written |
| 4 | HTTP Status Codes — and Who Sent Them | Read a status code as evidence about which hop failed | written |
| 5 | The Browser as a Debugger | Use DevTools Network, Console, Sources and Application with intent | written |
| 6 | The Request's Journey | Debug DNS, TCP, TLS, caching and CDNs with curl | written |
| 7 | Logs | Read, search and correlate logs during an incident | written |
| 8 | Inside the Node Process | Breakpoints, profiles, event-loop lag, memory growth | written |
| 9 | Inside the Database | Find the blocking query, the lock, the exhausted pool | written |
| 10 | Production Observability | Go from an alert to a root cause with metrics and traces | written |
| 11 | Casebook I — "It Works on My Machine" | Build vs runtime config, case-sensitive paths, time zones, hydration, sessions across instances, version skew, CORS | written |
| 12 | Casebook II — Caching | Stale data, invalidation, cache keys that leak data, stampedes, Next.js, browser, CDN and Redis caches | written |
| 13 | Casebook III — Slow, Flaky, and Falling Over | Tail latency, 502/504 chains, retry storms, memory leaks, double writes, cascading failures, stuck queues | written |
| 14 | Casebook IV — "Nobody Changed Anything" | Time bombs, time and calendars, dependency drift, third-party changes, flaky tests, git bisect | written |
| 14B | Casebook V — React and React Native | Render loops, stale closures, index keys, out-of-order responses, StrictMode double effects, re-render profiling; Android networking, release-only crashes, OTA version skew, list jank | written |
| 15 | Incidents, Postmortems, and the Story | Run an incident, write a postmortem, tell the story in an interview | written |
How to Read Each Chapter
Every chapter in Parts 1 and 2 follows the same shape:
- The mechanism. What the thing physically is and why it exists.
- The vocabulary. The words engineers actually use, defined precisely — so you understand them in a standup and use them correctly in an interview.
- The Causal Chains. "If you see X → it means Y → so check Z." These are rendered as a self-test: the consequence is hidden until you predict it.
- The Rule You Keep Forever. One sentence per idea that survives after you forget the details.
- Practice problems. Short scenarios. If you can answer them out loud, you own the chapter.
Where a chapter has a step-by-step timeline, step through it and type your prediction at each pause before revealing. The prediction is the learning; reading the answer is not.
How This Connects to the Rest of the Reader
This track does not repeat material the reader already covers in depth. It links to it and spends its words on using it during an investigation:
- Heap snapshots and leak patterns → FE-07 — Memory, Leaks & the Browser Heap
- Performance measurement and RUM → FE-08 — Measuring Performance
- Logs, metrics and traces as concepts → Q53, Q54, Q55
- The slow-query workflow → PostgreSQL Ch 19
- Locks, deadlocks and race conditions → PostgreSQL Ch 14–16