When I join a new project, I deliberately don't try to understand the entire codebase at once. The temptation is to spend the first week reading every file to build a complete mental model, but that approach fails for any codebase large enough to be worth working on — you forget the beginning by the time you reach the end, and you haven't actually used any of the knowledge to do real work. Instead, I start at the actual entry point — `main.tsx` or `App.jsx`, whichever applies — and follow the component tree outward from there, one level at a time. The entry point is where the application's structure becomes visible, because it's where all the top-level pieces are wired together.

As I go, I pay specific attention to data flow: where does data originate, what transformations happen to it as it passes through the component hierarchy, and where does it ultimately end up. Data flow is the skeleton of any application; once you understand how data moves through it, the rest of the code becomes much easier to understand because every component's purpose is clarified by the data it consumes and produces. I keep a running document of open questions — things I encounter that I don't yet understand, rather than stopping to resolve every single one in the moment. After roughly a week, most of those questions answer themselves as I see more of the system in context, and the ones that remain are genuinely worth interrupting a teammate to ask about.

The underlying goal isn't to reach a state of knowing everything about the codebase before making a change. That's impossible in any codebase large enough to be worth working on, and the attempt leads to analysis paralysis. The goal is to reach a state of knowing enough about the relevant area to make a safe, well-reasoned change without introducing a regression somewhere I didn't think to check. That level of understanding is achievable in days, not weeks, if you read strategically rather than exhaustively.