At first you really don't want to understand the code, you want to understand what it does. Nobody can suck in huge codebases and make sense out of them. So pi

At first you really don't want to understand the code, you want to understand what it does. Nobody can suck in huge codebases and make sense out of them. So pick some various things the program does and walk through them in the debugger. Do you understand what's happening? Why? Is there a clear pattern at work for how things are constructed, used, torn-down? Do that a few times with various behaviors. A good place to start is whatever the "init" functionality is, since everything else will use that. After you're comfortable with the patterns you're seeing, begin to move "vertically", looking at other methods in the module near the one you're interested in. Are there patterns to the way the modules are organized? Does it make sense? At some point, you'll have a good idea of whether or not you're in a strongly-patterned architecture or not. Strongly-patterned architectures may be huge and complex, but a small number of patterns can take you far. If not? You got a mess. Then you have a new question: how do I deal with this mess in front of me? ADD: An important point to understand about really complex and poorly-writen codebases is that they might not be understandable, at least overall. At some point when you're writing bad systems, you have a magic act, not a program.