There's actually two separate skills here. One is learning to just read code, as in, understanding what the code is saying. The second is understanding the code

There's actually two separate skills here. One is learning to just read code, as in, understanding what the code is saying. The second is understanding the code, which would be what the code is doing. Learning to just read the code requires writing alot in that particular language (I find writing teaches you alot more than reading). When some piece of code uses some aspect of a language in a way you don't understand, go figure out what they are doing, internalize that concept, and go write some code yourself that uses that same concept in that language. In my experience, writing alot of code is the best way to learn to read it. You'll discover and truly understand why certain things are done certain ways once you've had to go through the pain of doing it any other way. One of the 'first' examples you might run into is how every single header file in a c/c++ library seems to start with an #ifdef/#define combo, and end with an #endif. It might seem a bit bewildering at first. But when you run into your first case of multiple includes of the same file, you'll quickly see why they do it. As for actually 'understanding' a big pile of code, that's more difficult. This is where you understand the language just fine but you need to try to wrap your mind a giant pile of someone else's code. You have to immerse yourself in their codebase, figure out where all the important files are, and so on. Take it small chunks. Pick a feature, trace the code, put in print statements, etc. And you -really- need a way of quickly navigating the code (jumping to decelerations, switching between header/source, etc). Many IDEs provide some level of functionality to do this. Personally, I use emacs and etags.