[Minor49er]

I always approach a codebase with intent to change it, even if I'm just casually curious. This leads me to specific points deep in the codebase that naturally lead to more exploratory questions, such as how/when the execution path gets there, how the change can be tested, etc. In short, I try to look inside, then move outside.

Using blame or navigating closed issues can do a lot to put specific problems into plain English to help with this kind of inward-out exploration (which can also help with understanding the use cases of the application). Same with reading any tests that might be there. And if there aren't tests, writing them is a great way to get into understanding specific functionality.