Reading code is a different skill than writing it

Learning to program is almost entirely a writing exercise: tutorials, courses, and exercises overwhelmingly have you write code from nothing. Real engineering work flips this ratio — understanding an existing codebase before making any change, tracing through someone else's logic to find a bug, reviewing a teammate's pull request — is the majority of most working engineers' actual time. Being a strong writer of code doesn't automatically make you a strong reader of it; they're related but genuinely separate skills, and the second one is rarely taught directly.

Reading an unfamiliar codebase front-to-back like a novel almost never works — codebases aren't written to be read linearly, and most of any given file is irrelevant to whatever you're actually trying to understand right now. Reading code effectively means reading with a specific question in mind:

A very common, costly mistake when reading unfamiliar code: assuming that code you don't understand must be a bug, and "fixing" it — only to discover it was handling a real, specific edge case you didn't know about, and the "fix" just reintroduced that bug. The right instinct when code looks wrong but you're new to it: understand why it's shaped that way first (git blame, related tests, asking someone) before assuming it's actually incorrect.

Nearly everything in this lesson is also, directly, the foundation of effective debugging (the next lesson) — you cannot isolate where a bug lives in a system you don't know how to navigate, and the "trace with a specific question" approach here is exactly the same skill applied to "why is this producing the wrong output" instead of "how does this feature work."