The Skill Nobody Tells You About: Reading Code

There's a weird moment in every new engineer's life when they realize their job title is a bit of a lie.

You were hired to "write code." Most days you barely write any. You open a file someone else touched two years ago, read it for forty minutes, add four lines, and go home. Nobody warns you about this in college.

Tutorials give you the wrong idea about this job, honestly. Every exercise starts with an empty file and you build something from scratch, so you assume that's what the work looks like. Then you get an actual job and inherit a codebase someone else built, sometimes years ago, sometimes by people who left the company before you joined. Nobody hands you a blank file. They hand you a few hundred thousand lines and a bug report.

The Ratio Nobody Talks About

New engineers find this part surprising, and I did too. Writing feels like the real work, the part you get judged on. Reading feels passive, like you're stalling before you actually do something. But the ratio in real jobs leans hard the other way. I've heard experienced developers put it at eight or nine times more reading than writing, and honestly that tracks with what I've seen. Every bug fix starts with reading. Every new feature means reading the surrounding code so you don't duplicate something or break an assumption buried three files away. Even writing brand new code involves a lot of reading, documentation, old commits, error messages that are really just the code talking back to you.

Why AI Makes This More Important, Not Less

AI tools have made writing code faster than it's ever been, which is exactly why reading well matters more now, not less. A model can spit out a working function in five seconds. That changes the bottleneck completely. It's not "can I write this" anymore, it's "do I actually understand what just got written." I've watched people accept AI generated code, ship it, then spend three times as long debugging it later because they skimmed it instead of reading it. It looked fine. It read fine. Typing code got cheap. Understanding it did not, and that gap is where a lot of the real skill sits now.

Reading and Writing Are Not the Same Skill

You can be good at one without being good at the other. I know engineers who can write clean, fast, idiomatic code in three languages and still get completely lost reading someone else's fifty line function. Writing rewards fluency, knowing the syntax cold, turning an idea into working logic fast. Reading rewards patience, honestly, and a kind of detective instinct. Why is this named the way it is. Why does this check for null twice when the type system already handles that. Good readers ask this stuff almost without thinking about it, and they hold off on rewriting something the second it looks messy. A lot of the time messy code survived problems you haven't run into yet.

The Old House Analogy

It's a bit like inheriting an old house instead of building a new one on an empty lot. Anyone can nail up a wall where there was nothing before. If you're renovating something fifty years old, you'd better know why that ugly wall is load bearing before you take a hammer to it. That's why experienced engineers poke around for a long time before they touch anything.

I still catch myself wanting to rewrite unfamiliar code way too early. First codebase I inherited, I spent a whole week trying to "clean up" some function before realizing the weird parts were handling a payment edge case that would've cost the company real money if I'd removed it. Nobody told me that. I had to sit with the code long enough to notice it myself.

If You're Early in Your Career

If it feels like you're not producing enough because you spent an hour reading before writing three lines, that's not wasted time. That's most of the job, actually. The engineers people trust with the messy, high stakes parts of a system usually aren't the fastest typists in the room. They're the ones willing to sit with code they didn't write, resist the urge to bulldoze it out of frustration, and figure out what it's actually doing before deciding what to change.

Writing code is easy to point at and measure. Reading it well is quieter, harder to fake, and it's usually the thing standing between a system that holds together and one that doesn't.