Recently, during one of my onboarding calls, I got a piece of advice that instantly clicked:
To learn a codebase — especially a big, complex one — don’t read the code. Read the PRs.
It made immediate sense, because up until that point I’d been doing exactly the opposite. Spending hours diving through the codebase, and not really learning much.
Sure, poking around the files gave me a general sense of structure and architecture. I could connect most of it to patterns I already knew. But would I have felt confident making changes? Absolutely not. The gaps were too big, the context too thin.
My first approach was to narrow my focus. I’m in a team that owns a specific area of the app, so I zeroed in on those pages, got familiar with the key components and patterns, and tinkered locally. That got me moving faster, but still didn’t give me the bigger picture.
Another trick I’ve used in the past is to explore the app itself. Not the code, but the product. Clicking through features, seeing how it behaves, and then tracing those behaviours back to the code. It’s great for understanding the finished product, but again, it’s only one piece of the puzzle.
Reading PRs, though? That’s a game-changer.
In smaller teams I’ve worked in, PRs were often just a formality. Even when they were taken seriously, I only paid attention to my own, maybe skimming others if they touched my work. I never thought of them as a learning tool.
Now I see it: PRs are a living record of how the codebase evolves, with all the context, discussion, and trade-offs laid out for you. They’re the closest you can get to sitting over someone’s shoulder while they work.
We have a Slack channel that collects all open PRs, so finding good “study material” is easy. I started with things I could understand right away: a small UI tweak, a component refactor similar to mine, a bug fix on a familiar pattern. Each one taught me something: about style, about decision-making, about pitfalls to avoid.
It feels like an ongoing, real-time masterclass in good development practices. And the best part? It’s specific to the codebase I’m working in, the people I’m working with, and the product we’re building.
It’s still early days, but already I can feel the benefits. I’m connecting more dots. I’m picking up approaches I wouldn’t have thought of on my own. And I’m getting a sense of the “why” behind the code — not just the “how.”
I’ll definitely keep at it. This is one habit I don’t see myself dropping anytime soon.