I usually get to the code when I have a purpose beyond merely understanding the project, like wanting to make a change or just understand why a certain behavior

I usually get to the code when I have a purpose beyond merely understanding the project, like wanting to make a change or just understand why a certain behavior is like it is. After I've downloaded the project, I'll think of a few words that are related to what I want. For example, in the program "sweep", an audio editing program, there's currently a bug where the arrow in the horizontal ruler gets redrawn, but the horizontal ruler as a whole doesn't. That causes overlapping drawings of the arrow to be drawn in a similar fashion as when a program with a window freezes and you move another window over it. So, I'll think of the words "arrow", "cursor", "ruler", "point", etc. and grep them in the code. The grep's/ag's -C option is awesome for this, too. I'll look over the matches and visit the matches that look the most relevant to what I'm looking for. This is easier when what you want is logically near text that the program outputs or that you otherwise know must be in the code. That way, you don't need to guess. For example, to modify gnupg so that you can change the directory it uses for socket files with an environment variable, you can just grep for something like the filename of a certain socket like "S.gpg-agent" and look at the code for where the directory path comes from. That's pretty much guaranteed to quickly take you to where you want to go. grepping is awesome. It's simple and works with every language.