Reading Code Is the Skill Nobody Practices
We spend enormous energy learning to write better code. Almost none on learning to read it. That imbalance is worth thinking about.
Almost every programming resource teaches you to write code. Very few teach you to read it.
There are courses on algorithms, architecture, design patterns, testing, performance, and system design. Books on clean code, readable code, maintainable code. Almost all of them are, fundamentally, about the act of producing software.
But most of what an experienced engineer actually does at work is read.
What reading actually means
Not skimming. Not cmd+f-ing for a function name and reading just that function. Actually reading — building a mental model of what a piece of code does, why it does it that way, and what would happen if you changed it.
Good readers notice things:
- What's not there — the early return that prevents a bug, the validation that protects an invariant, the comment that's conspicuously absent
- When something is more complicated than it needs to be — often before they can articulate exactly why
- The seams — where one abstraction ends and another begins, and whether that boundary makes sense
- Surprises — lines that make you pause, even briefly, are almost always worth a second look
These are learnable skills. They're not mystical senior engineer intuition. They're pattern recognition built through practice, the same way you get better at reading prose by reading a lot of prose. The only way to develop the sense that something is off is to read enough code that you've internalized what "not off" feels like.
Why this matters more now
There's a new context in which reading has become even more important: working with AI-generated code.
AI tools produce code at a pace that can dramatically outrun your ability to understand it, if you let it. The temptation is to read just enough to convince yourself something works. That shortcut has a cost that doesn't show up immediately — it shows up when something breaks and you realize you don't actually understand the system you're debugging, or when you need to extend a feature and you're working in a fog.
Every line you commit without understanding is debt. Not the kind that accrues interest — the kind that compounds.
The engineers I've seen get the most out of AI coding tools treat the output as a first draft. They read it the same way they'd read code from a junior engineer: with attention, with skepticism, with the assumption that they might catch something worth catching. That's not distrust — it's just how you maintain ownership of your codebase.
How to actually practice
Reading is a skill, which means it responds to deliberate practice. A few things that have worked:
Read open source code in languages you know well. Not to learn the library — to watch other engineers make decisions. Why did they name this? Why structure it this way? What constraint explains this choice that looks weird at first glance?
Read your own code six months later. This is humbling in exactly the right way. You'll find things that made sense in the moment and make no sense now. That's signal. It tells you what you were optimizing for, and whether you were optimizing for the right thing.
Explain code out loud. Narrating what code does forces you to confront the places where your mental model is fuzzy. If you can't explain it clearly, you don't fully understand it. This sounds obvious. It's more revealing than it sounds.
Read diffs, not just code. The diff is where the decision is. Reading a file tells you what the code does now. Reading the diff tells you what changed, and sometimes — if the commit message is good — why. That context is often more valuable than the code itself.
The payoff
The engineers who are genuinely dangerous — in the good sense — aren't always the fastest writers. They're the ones who can walk into an unfamiliar codebase and quickly build a model of how it works: where the load-bearing pieces are, what the failure modes look like, where the bodies are buried.
That's a reading skill. It's worth treating it like one.
Bonus: reading is also how you develop taste. The code you read shapes the code you write. Choose your influences deliberately.