The instinct when you open an unfamiliar repo is to start reading main.py or index.ts top to bottom like a novel. This doesn't work — you'll be three files deep into imports within five minutes and have no idea what you're looking at. Here's the order that actually works.
1. Read the README and CONTRIBUTING.md first, fully
Not skimmed — fully. The README tells you what the project believes it does. CONTRIBUTING.md tells you the process the maintainers actually enforce: how they want commits formatted, whether they require an issue before a PR, what their test coverage expectations are. Skipping this is the single most common reason a first PR gets stuck in review for weeks.
2. Run it before you read it
Get the project running locally before opening a single source file. A codebase you can't run is a codebase you're reading blind — you have no way to check whether your mental model of what a function does matches what it actually does.
3. Find the entry point, then follow one real request end to end
Don't browse the file tree. Pick one concrete thing the app does — a button click, an API request, a CLI command — and trace it from the entry point through every function it touches, ignoring everything else. This gives you one real, working mental model instead of dozens of half-understood fragments.
User clicks "Submit"
→ onSubmit handler in Form.tsx
→ calls submitOrder() in api/orders.ts
→ POST /api/orders
→ validateOrder() in server/validation.ts
→ OrderModel.create() in server/models/order.ts
That trace is worth more than an hour of skimming random files.
4. Read the tests before you read the implementation
Tests are documentation that can't go stale, because they break the build if they lie. If you want to know what a function is actually supposed to do — including the edge cases nobody wrote a comment for — the test file next to it usually says it more precisely than the code itself does.
5. Grep before you guess
Before assuming you understand how something works, search for it:
grep -rn "validateOrder" src/
Nine times out of ten, a function is called from more places than you expect, and one of those call sites will correct an assumption you didn't know you were making.
6. Pick the smallest possible first issue
Not because you're not capable of more — because your first PR to a new codebase is really a PR to learn the review process, not to prove you understand the whole system. A typo fix, a missing test case, a small validation bug. Get one merged, see how the maintainers give feedback, and use that as your calibration for everything after.
This is the same order we point new contributors toward before their first PR into any of the orgs the club works in — it scales down to a 200-line utility library and up to something the size of Zulip or Kubernetes.