Reading Other People's Code Is a Skill. Train It.

Nobody teaches you how to read code. You get tutorials that walk you through writing it, courses that have you build things from scratch, challenges where you produce output from a blank file. But the moment you join a real team and open a real codebase — thousands of files, no author to ask, no walkthrough — you're on your own. And most developers are much worse at this than they realize.

What I do when I open an unfamiliar codebase

I don't start at the top of the file tree. I start with the entry point and follow the data. Where does it come in? Where does it go? What touches it along the way? This gives you a spine — a single thread through the system you can hang everything else on. Once you have that, the rest of the codebase stops feeling like a maze and starts feeling like a map.

The thing it does to your own code

This is the part that surprised me most. Deliberately spending time reading other people's code made me a significantly better writer of it. You internalize what confuses you. You notice when a function is doing three things and none of them are obvious from the name. You feel the cost of a missing comment in a non-obvious place. You start writing for the next person who has to read it — because you've been that person, and you remember what it felt like.

The best way to learn how to write clear code is to suffer through unclear code long enough to understand why it hurts.

— Zaid Maraqa

How to actually practice it

Pick an open source library you use and read its source. Not the docs — the actual code. Start with a function you call regularly and trace what it does. Read good PRs on public repos and try to understand the reasoning before you read the description. When you're reviewing code at work, go deeper than correctness — ask yourself if you could explain what this does to someone who's never seen the codebase. If you can't, that's signal.

It compounds

The developers I've learned the most from aren't the ones who write the most impressive code. They're the ones who can sit down with any codebase, get oriented fast, and start contributing without needing a guided tour. That skill doesn't come from building more side projects. It comes from deliberately reading code you didn't write, in contexts that aren't comfortable, until it stops feeling foreign.

Especially now, with AI in the picture

If you're using AI to help you code — and you should be — reading code becomes even more critical, not less. AI will generate things. Sometimes they're correct. Sometimes they're plausible-looking and subtly wrong. Sometimes they solve the problem you described but not the problem you actually have. The only way to catch that is to read what came out carefully, trace it through your system, and know whether it fits. Developers who can't read code fluently are going to blindly accept AI output and ship bugs they don't understand. Developers who can are going to use AI as a force multiplier and actually know what they're shipping.