You spent years learning to write code. You'll spend your career reading it — and almost nobody trains for the thing you'll actually do most.
Every course, tutorial, and coding challenge optimizes for one skill: producing code from a blank page. Then you get a real job and discover the blank page is the rare part. The job is mostly reading — and reading code is a distinct skill that most engineers never deliberately build.
The ratio nobody mentions
On any real system, you read far more code than you write. Before you can add a feature, you have to understand the code around it. Before you fix a bug, you have to find it, which means reading until you understand what's actually happening. Even writing new code means constantly reading the existing patterns, APIs, and conventions you're building against.
The blank-page skill you spent years honing is the small slice. The dominant activity is comprehension — building an accurate mental model of code someone else wrote, often years ago, usually with no one around to explain it. And unlike writing, most people were never taught to do it well.
Why reading is genuinely hard
Reading code is harder than reading prose because you're not just parsing what it says — you're reconstructing why. What was the author trying to do? What can I safely change without breaking something three files away? Which of these branches actually runs? You're reverse-engineering intent and behavior from a static artifact, holding a model of a running system in your head.
This is exactly why tooling that helps you understand a codebase — not just edit it — is so valuable. It's the reason I built a code-graph engine into one of my AI systems: give the machine a structural map of the code so it can navigate and reason about it, instead of guessing. Comprehension is the bottleneck, so comprehension is worth engineering for.
How to read code better
A few things that separate people who parachute into an unfamiliar codebase and get productive fast:
- Start from an entry point and follow one path. Don't try to understand everything at once. Pick one real flow — a request, a click, a command — and trace it end to end. Depth on one path beats a shallow scan of everything.
- Read the tests. They're executable documentation of what the code is supposed to do, and they show you how it's meant to be used.
- Change something and see what breaks. Running the code and poking it teaches you faster than staring. The debugger is a reading tool.
- Resist rewriting on sight. Code that looks wrong is often load-bearing in ways you don't see yet. Understand why it's like that before you "fix" it — the ugliness may be a scar from a real bug.
The takeaway
If you want to level up as an engineer, get deliberately good at the thing you actually do most: reading. The ability to drop into a large, unfamiliar codebase and build an accurate picture of how it works is one of the highest-leverage skills in the field, and one of the least taught. Writing code gets you in the door; reading it is how you become genuinely dangerous. More on how I think about building and understanding systems at www.divyakush.com.
Related reading
- Saturday MK1: an AI assistant that's a system, not a prompt — including a code-graph engine built specifically to understand a codebase.
Top comments (0)