How do you practice reading an unfamiliar codebase?

Start with the bug, not the whole project. Reproduce it, note what you expected and what happened, then look for an error message, stack trace, or relevant input that gives you a starting point.

Set a breakpoint there and step through the code. Check the values going in and coming out, then follow the calls that seem relevant. A few test cases that make the bug appear or disappear can narrow things down a lot. You only need enough of a map to explain the behavior you're investigating.

Pick an active open source project and try a small issue. Before changing anything, find the relevant code and tests, then write down how you think the behavior works. Run the tests and see whether your explanation holds up.

Code reviews are useful practice too. You can trace a proposed change through its callers and tests, even when you aren't the person writing it.

Be cautious about assuming confusing code is simply bad. There may be old requirements or edge cases hiding behind an awkward implementation. Look at the tests and commit history for clues, and ask a teammate when the reason still isn't clear.

That's not an argument for never cleaning things up. It just helps to understand what behavior needs preserving before doing a big rewrite.

Use your editor's navigation tools deliberately. Go to definition, find references, search for distinctive error text, and leave bookmarks or notes as you trace a path. Otherwise it's easy to end up clicking around without remembering why you opened each file.

Comments and documentation can help orient you, but check them against the current code and tests. They may not have kept up with changes.

An AI coding tool can suggest where to start or explain a section you find confusing, but treat its answer as a lead, not proof. Follow the suggested path in the code and verify it with tests or a debugger. For work code, check your team's rules about which tools and access are permitted first.