Robert Martin estimates the ratio of time spent reading code to writing it at 10:1. Yet almost every learning platform trains you to write. Reading someone else's code is a different skill — and one you can improve deliberately.
When you read your own code, you fill in gaps from memory. You know why the variable is named that way, what the edge case is, what the original intent was. Reading someone else's code strips all of that away. You are reconstructing intent from syntax alone.
This is not an intelligence problem. It is a working memory problem. Unfamiliar code has no pre-built chunks in your mind — every line costs more cognitive effort to parse. The goal of deliberate practice is to build those chunks so more of your mental budget goes toward understanding rather than decoding.
Don't start reading at the top of a file. Start at the entry point: the function that gets called first, the endpoint that handles the request, the main() that kicks everything off. This gives you a thread to follow instead of a pile of context to hold.
From the entry point, read breadth-first before depth-first. Understand what the top level does before diving into implementation details. Ask: what does this function call? What does it return? Only then descend.
Program comprehension research by Soloway and Ehrlich identified 'beacons' — specific high-signal elements in code that experienced developers scan for first. These include function and variable names, return types, exception handling, and loop conditions. Novices read code linearly; experts jump to beacons.
When you open an unfamiliar file, train yourself to scan before you read. What are the public method names? What types does this class own? What does the constructor touch? These beacons give you a structural map before you've read a single line of logic.
When you drop into a new codebase, a single file tells you almost nothing. The architecture tells you everything: is this layered (controller → service → repository)? Event-driven? Hexagonal? Monorepo with shared packages? Recognizing the architectural pattern immediately tells you where business logic lives, where side effects are expected, and what the boundaries are.
Before reading any implementation, look at the top-level folder structure, the dependency graph (package.json, pom.xml, go.mod), and any README. Five minutes at this altitude saves thirty minutes of confused file-hopping.
Legacy code is code that works but no one fully understands anymore. The original author is gone, the comments are stale, and the tests either don't exist or don't cover the scary parts. This is the hardest reading environment — and the most common one in real jobs.
Three tactics that work: first, find the change log. Even one-line commit messages from three years ago reveal what the system used to do versus what it does now. Second, look for the 'seams' — places where the code calls out to external systems or changes behavior based on configuration. Seams tell you what the author expected to vary. Third, write characterization tests as you read: small tests that capture what the code does today, not what it should do. Each test is a verified fact about the system.
Reading code in an unfamiliar language is less about syntax and more about pattern recognition. Every language has idioms — standard ways of expressing common operations. A Python list comprehension, a Go defer statement, a Rust ownership transfer — these are not syntax puzzles, they are patterns that carry meaning once recognized.
The fastest path into an unfamiliar language is not a tutorial. It is reading idiomatic code and asking: what problem does this language feature solve? Why would the author write it this way instead of the way I would write it in my language? The answer is usually a constraint the language was designed around.
Every function depends on something: other functions, external state, injected services, global variables. Before reading what a function does, list what it depends on. This dependency map tells you the blast radius of any change and reveals hidden coupling that the code structure does not make obvious.
In practice: read the function signature and the imports. Note every external symbol the function touches. If you find a function that depends on seven things, that is information about the design — not just a reading challenge. Understanding why so many dependencies exist often requires git history, not just the code itself.