Reading someone else's code without drowning

Why this is the main skill

At work you'll read far more code than you write. You join a project with a hundred thousand lines written before you, and the first task is not to break what you don't understand.

Beginners don't expect this: they were taught to write from scratch. Which is why the first weeks on the job are hard — and why the skill is worth practising in advance.

An order of operations

1. Don't start with the code. Read the README first, look at the project from outside: what it does, who uses it, what sections exist. Without that, code is just letters.

2. Run it. Until it works on your machine, investigation is pointless. It often takes a day, and that's normal.

3. Find the entry point. Where execution begins. In a web project, the request handlers; in a utility, the main function.

4. Trace one scenario end to end. Pick a single user action and follow the path: where the request is received, where data is validated, where the database is consulted, what comes back.

One traced scenario yields more understanding than a week of unsystematic reading.

5. Draw a map rather than memorising. Sketch where things live and what calls what. In a week you'll be glad of it.

Techniques that help

Read top-down, not sequentially. Folder structure first, then large pieces, then details. Don't start with the first file alphabetically.

Use the debugger. Setting a breakpoint and inspecting values beats guessing from the source.

Change things and watch. A safe way to understand a section is to break it deliberately and see what stops working.

Read the commit history. It shows why the code is the way it is. A strange decision is often explained by one line in a commit message.

Don't try to understand everything. Understanding the part you need is enough. Nobody holds a whole project in their head, including its authors.

What not to do

• Don't rewrite immediately. The temptation is strong: "this is all terrible, I'll redo it". Usually there's a reason behind the strange decision that you don't know yet.
• Don't stay silent for a week. Half an hour trying, then ask. Silent grinding reads not as independence but as an inability to ask for help.
• Don't judge by style. Code written differently from your habits isn't necessarily bad.

Practising before you have a job

Read open source. Take a small project in your language and trace one scenario end to end.

Submit a change to someone's project. That forces real understanding: to fix something you must understand its surroundings.

Work alongside someone. The fastest route: on a shared project you read someone's code and explain your own every week. Two months of that grows the skill more than six months of reading alone.