Dropped into an unfamiliar codebase, most people start reading files top to bottom and drown by lunch. That’s the wrong entry point. Code isn’t a book, it’s a graph, and you need to walk the graph, not the alphabet.

Start from behavior, not structure

Don’t open the file tree first. Open the app and click through it, or hit the API with curl. Find three or four things it actually does, and use those as your anchors. Structure without behavior is just a list of nouns — you need the verbs first.

1. Find the entry points

Every codebase has a small number of places where the outside world comes in: HTTP routes, queue consumers, CLI commands, cron jobs. Find these before anything else — grep for the router setup, the main() function, the job scheduler config. This is your map’s edge; everything else is reachable from here.

grep -rn "app.get\|app.post\|router\." src/ | head -30

2. Pick one request and trace it end to end

Take the single most important user action — login, checkout, whatever the business actually depends on — and follow it from entry point to database and back. Don’t try to understand every branch, just the happy path. Write it down as a list, not a diagram: route handler → validation → service call → query → response shape.

This one trace teaches you the layering conventions (is there a service layer? a repository layer?), the naming conventions, and the error handling pattern, all at once, anchored to something concrete instead of abstract.

3. Find the tests before you trust the docs

Tests tell you what the previous team actually cared about protecting. Docs tell you what someone thought was worth writing down at some point in the past, which may or may not still be true. Read the test file names first — they’re a table of contents for what’s considered a “risk” in this system.

4. Look at git history, not just current state

git log --oneline --follow -- path/to/weird-file.js

A file that’s been rewritten eight times has a story. git blame on a confusing line often leads to a commit message or PR that explains a workaround for a bug that no longer has a ticket anywhere else. This is the fastest way to recover institutional knowledge that left with the person who wrote it.

5. Find the load-bearing files

In most codebases, 20% of files carry 80% of the complexity — the core domain model, the main state manager, the central config. Find them by looking at what gets imported everywhere:

grep -rl "from.*['\"].*config['\"]" src/ | wc -l

High import counts mean high blast radius. Know these files before you touch anything near them.

What to skip

Don’t try to understand every utility function on first pass. Don’t read the CSS. Don’t try to memorize the folder structure — you’ll absorb it naturally as you trace real flows. Trying to build a complete mental model before writing any code is how people spend three weeks “getting oriented” and ship nothing.

The one-day target

By the end of day one you should be able to answer, without looking: where does a request enter, where does data get persisted, and where would you add a new field to the main entity. That’s not mastery. That’s enough to make your first small, safe change — and the fastest way to actually learn the rest is to make that change and watch what breaks.