i'm not sure there's a good answer to this, apart from "keep trying and become a better programmer", but maybe if i explain why it is hard to read code it will help you see how to improve.

the trouble with most programming languages is that they are pretty much stuck at one level of detail. so at the level of detail of "add these numbers" or "print this text" they are ok.

but when you get to higher levels, like "while reading the file, get the input from the user" they don't do as well. as a programmer you are "trapped" using the same language that was designed to make working with the low level details possible.

this is what makes programming hard/interesting, really. and of course there are lots of ways to try solve the problem. one approach you might have met if you've been reading what pg writes is to use a language like lisp which is extensible (i'm thinking of his book "on lisp", which i think is online now). then you can build the language up in parallel with your ideas so that you continue to use a language at the right level for what you are describing.

in theory at least. in practice it is not so easy, and we have to read code written by poor or average programmers, as well as good ones.

another way to deal with the problem is to keep thinking about things at a higher level, even if you are stuck with a language that forces you're writing to spell things out in detail.

if a program is written by someone working in this way (thinking big thoughts) then what you need to do is guess what they were thinking. once you (correctly) guess the ideas behind the code then you can see the structure that is otherwise obscured by all the details (like not being able to see the wood for the trees).

obviously that's an impossible task in general - you cannot guess what someone else is thinking. but in practice it turns out that some ideas are a lot more popular than others. often because they are good ideas; sometimes because they are common mistakes.

so one way of getting better at reading code is to learn what the possible ideas are. then, when you read the code, you can pick that up. it might take some effort at first, but eventually you get good at picking up "the scent".

for example, yesterday i was trying to understand why some code wasn't working (part of the excellent sqlalchemy library for making python work well with sql databases). stepping through the code in the debugger i was completely lost - i couldn't have told you in any detail what was happening. but at the same time, i was pretty sure that i knew what was happening in broad terms. the library was written in a way that made it very customizable, with lots of work being delegated to function calls that could be replaced in various ways. this is a common idea for complex libraries, so i wasn't too worried that i didn't know the detail of function calling function calling function because i was pretty sure that the end result was just to delegate the process to the right part of the library. understanding what the idea was made it a lot easier to read (or skip parts of) the code.

sorry, i am writing too much. almost done.

anyway, for oo languages (particularly those with fairly rigid type systems - java, c++, etc) some of these ideas are documented as "patterns". even in other languages, som e of these ideas are so general they appear there too (but with different names :0). so one way to improve your code reading skills is to first understand the patterns, so that you have a catalogue of ideas that you can check against the code (or against what you think was in the programmer's mind when they wrote the code). the most famous book that talks about patterns was also the first (afaik) and is called "design patterns" -http://en.wikipedia.org/wiki/Design_Patterns