Most advice for new developers is about writing code. Practice problems, build projects, ship side projects. The implicit message is that programming is a generative skill, and the way to get better is to generate more.

I think this is backwards. The harder, more valuable skill is reading code.

The ratio nobody talks about

In any real job, you read far more code than you write. A small feature might be fifty lines of new code, but those fifty lines sit inside a codebase of fifty thousand. To know where they go, what they touch, what they break, you have to read.

Even within your own work, the ratio holds. You write a line, then read the surrounding function to check it fits. You read the test, run it, read the failure, read the code again. The keyboard is mostly idle. The eyes are not.

What good readers do

Watch a strong engineer drop into an unfamiliar codebase and you'll notice they don't try to understand everything. They form a hypothesis, then look for the smallest piece of evidence that confirms or kills it. They follow the data, not the file tree. They read the tests before the implementation, because tests describe intent and implementation describes mechanism.

They are also patient with not knowing. A weaker reader sees an unfamiliar pattern and either skims past it or spirals into a documentation hole. A stronger reader notes it, keeps going, and lets the meaning fill in from context. Most code, like most prose, is comprehensible from surrounding signal even when individual words are opaque.

How to practice

Pick a project you use and don't understand. Open the entry point. Trace one feature from the user-facing surface down to where the work actually happens. Don't try to memorise. Just follow the thread until you can answer one specific question: when I click this button, what happens?

Do that a few times and the codebase stops feeling like a wall and starts feeling like a map. Do it across enough codebases and you build an intuition for where things tend to live, which is most of what senior engineers actually have over junior ones.

The compounding is real. Every codebase you read makes the next one faster. Writing doesn't compound in the same way, because the problems are always new. But the shapes of code repeat.

The unglamorous part

Reading code is harder to show off than writing it. There is no commit, no demo, no green checkmark. You spend an afternoon understanding something and have nothing to put in the standup except "I read the auth module." It feels unproductive in a way that writing never does.

That feeling is the tax on the skill. Pay it anyway.