grep is your friend. Pick some aspect you want to learn about, select some text that's output or input in the user interface that should be relatively close in

grep is your friend. Pick some aspect you want to learn about, select some text that's output or input in the user interface that should be relatively close in the code, and grep it. Follow from there. Check what it does, appreciating the variable and function names that the writer picked so you wouldn't have to follow every function definition to understand what it does in a broad sense. When the writer didn't care to pick quickly understandable names it's probably that those things work arcane details that are of no interest to understand the greater picture of what's happening. In other words, skim for the informative names and deduct what's happening from them. Check what calls that code, where that code leads to, etc. When you get bored of these features, rinse and repeat from the top, selecting another feature by its UI output. Another technique is to just grep random things related to the program. For example, if it's a scroll shooter game, grep "bullet", "ship" and things like that. Checking the results gives you a good idea of where the most identifiable, high-level code is and how it's organized. When I started out, I thought the only sensible way was to find main() and read line by line, depth-first, following every function call, understanding every detail. It's not effective. You don't need every detail. You don't need to parse it like a computer. It's like sight. A computer will work, no problem, pixel by pixel, left to right, top to bottom. For us, it's more useful to just look and identify the most distinctive characteristics that we can work with. The ones that relate the most to how we can interact with the object.