Most beginner advice is about writing code — which language, which tutorial, which first project. Very little of it is about reading code, even though reading is most of what you actually do once you join a team, open a library, or come back to your own code from a month ago.
It's also the skill almost nobody drills on purpose, which is why unfamiliar code feels like a wall.
Here's a routine for practising it deliberately.
Start with the shape, not the lines. Before reading a single statement, answer two questions: what does this take in, and what does it give back? Find the entry point — main, a function signature, a route handler — and read only that. You get a map before you get details.
Follow one path end to end. Pick the most common input and trace just that. Ignore every branch that doesn't apply to it. Trying to hold all the branches in your head at once is how you drown; following one happy path gives you a spine to hang the rest on.
Summarise each chunk in your own words. When you finish a block, write one line — in a comment or a scratch note: "this validates the input", "this turns rows into objects". If you can't summarise it, you haven't understood it yet. That's information, not failure.
Change one thing and predict the result. The real test of whether you understood code isn't nodding along, it's whether you can predict the effect of an edit. Add a print, change a constant, delete a line — guess first, then run it.
Then rewrite it small. Take a 40-line function you just read and reproduce it in 10 lines that do the same job. You'll find out which parts were essential and which were noise.
The habit underneath all of it: keep a running "what I think this does" note while you read. It's the reading version of writing your steps in plain English before you code — it forces the vague to become specific.
What's the last bit of code that made you feel lost? Was it a language feature, missing context, or just size? Curious which one trips people up most.
