It really depends where you're starting from. If you don't have any idea what a particular piece of code does, finding that out is your first goal. If you can,

It really depends where you're starting from. If you don't have any idea what a particular piece of code does, finding that out is your first goal. If you can, ask someone: a two-sentence summary of what a module does can save you hours of digging through things, and takes almost no time for the person you're asking. From there, I have a couple of things I usually look at immediately. The most obvious thing to do is to try to find entry points into the code, and figure out what happens when those calls are made by reading sequentially. This is often the best way to work, although not always. The second thing to do that can be very helpful is to look at the external library calls that are being made. Those can give you an idea of what the code is actually affecting, which can be very helpful for getting a high-level overview. Another entry point is state that's being kept and modified from multiple locations. (Figure out what's being stored and why by looking at the code around where the state is modified.) One last thing you might try to do is reformat the code if it's particularly ugly. I try not to refactor unless I understand what's going on so I don't introduce bugs, but just reformatting can make a big difference sometimes if the style of the person who wrote the code is significantly different from your own. (And truth be told, 1000 lines of code in one file isn't that bad. When you start working with multiple files, some sort of method of jumping to function/method definitions becomes extremely useful. Since I use Vim, I often use something like ctags. Knowing how to use Unix tools like find and grep is also extremely helpful.)