How I read code I don't understand
A few things that actually work, and a couple of things that feel productive but aren't.
I spend a lot of time reading code I didn't write and don't immediately understand. Here's what I've figured out works.
What doesn't work
Reading linearly from the top. This feels organized. It isn't. Code isn't a book; most files are not written to be read start to finish.
Trying to understand everything before changing anything. You'll never feel ready. At some point you have to touch something, see what breaks, and learn from that.
What works
Start from behavior, not structure. What does this code do? Find the function that does the thing you care about and work outward from there. Don't start from the file tree.
Run it first. If there's a way to run the code and observe what it does, do that before reading any of it. Having a mental model of the output makes the source make more sense.
Use the test suite as documentation. Tests describe the expected behavior in executable form. If the tests are good, they're often more useful than comments.
Write down your current theory. When I'm confused, I write a sentence: "I think this function takes X and returns Y, but I don't understand why it calls Z." Writing it down forces me to be specific about what I actually don't know. Usually the next step becomes obvious.
Accept that you'll understand it piece by piece. You don't need a complete mental model to contribute. You need a good enough model for the thing you're doing right now. The full picture assembles over time, from repeated small interactions with different parts.
The uncomfortable truth
Most of the time I feel like I understand code less than I should. I've started to think that's just what it feels like to work in a codebase you didn't build — the experienced people feel it too, they've just made peace with it.
You don't need to understand everything. You need to understand enough.