Reading other people's code all day is an underrated skill

If you tracked actual minutes across a normal working week, writing brand new code would lose badly to reading code someone else wrote, often someone else six months ago who has since forgotten why they wrote it that way. Bug fixes start with reading. Code review is reading. Onboarding onto an unfamiliar service is reading. Even writing a new feature usually starts with reading three existing files to figure out where it’s supposed to plug in. And yet almost nobody treats reading code as a skill with its own technique, worth getting deliberately better at. It’s the thing everyone assumes just happens as a byproduct of years on the job, the same way nobody explicitly trains “remembering where things are” and just expects it to accumulate.

The habit that actually made it faster

The moment this became visible to me was joining a codebase for a client project with almost no documentation, a mid-sized Laravel app that had been through three previous developers, none of whom were reachable anymore. My first instinct, the one I’d used for years without questioning it, was to start at the top of the file structure and read outward, controllers first, then models, then whatever else looked important. It’s an exhausting way to learn a system, because you’re building a mental model out of parts before you know which parts matter, like reading a phone book to understand a city.

What actually worked, once I forced myself to try it, was starting from one real, specific thing the app needed to do, a user resetting a forgotten password, say, and tracing that one path end to end: the route, the controller method, the validation, the actual side effect, the response. That one path touches maybe six or seven files out of the two hundred in the project, but by the end of tracing it, I understood not just those six files, I understood the general shape the whole app uses for a request, because most requests in a reasonably consistent codebase follow the same shape. The second path I traced, an entirely different feature, took a fraction of the time, because I already recognized the skeleton and was just filling in what was specific to that feature.

The second habit that helped was reading the tests before the implementation, when tests existed. A decent test suite is a list of the behaviors someone thought were important enough to protect, written in plain assertions, which is a much faster way to learn what a function is actually supposed to do than reading the function itself and reverse-engineering intent from implementation details. Tests tell you the what. The implementation tells you the how. Reading the what first means you’re evaluating the how against something, instead of just trying to hold the whole thing in your head with no anchor.

Why this doesn’t get treated as a skill

Nobody asks about this in an interview. Technical interviews test writing code from scratch, on a mostly blank problem, which is close to the least common thing you actually do once employed. I’ve never once been asked in an interview to open an unfamiliar repository and explain, in fifteen minutes, what a specific function does and why it’s probably written that way. That would be a far more representative test of the actual job than most of what gets asked, and it would be much harder to prep for with memorized patterns, which might be exactly why it doesn’t happen, nobody’s built the industry-wide practice infrastructure for it the way they have for algorithm questions.

Because it’s untested, it’s also unpracticed on purpose. People get faster at reading code the same way people got faster at typing before typing was ever explicitly taught, by doing enough of it that the skill quietly improves as a side effect. That works, eventually, but it’s slow and accidental compared to what happens when you notice the skill exists and start deliberately building habits around it, tracing one real path instead of reading top to bottom, reading tests before implementation, refusing to touch a piece of code until you can explain in one sentence what it does and why someone probably wrote it that way.

Comprehension speed compounds

The payoff compounds in a specific way that writing speed doesn’t. Getting faster at typing code saves you seconds per line. Getting faster at reading unfamiliar code saves you the difference between a three-day onboarding and a three-hour one, on every new codebase, every new teammate’s pull request, every incident where the person who wrote the broken code isn’t in the room anymore. That’s a much bigger lever, and it’s sitting there mostly untouched, treated as a personality trait some engineers happen to have instead of a specific, learnable habit worth building on purpose.