Does this book help answer this question? I think so. In any case, I am grateful for your contributions towards making Computer Science even more humane. I wish you well and look forward to reading the book.
Thank you for the question: How can one learn to read code that other people wrote even faster than they do now? There is an apparent contradiction here: if people write even faster, then they will take less care to communicate with others, so the code will be harder to read (driving up downstream costs, reducing the lifetime of systems, damaging the reputation of our craft, etc.)
The way out of this contradiction was to take a step back and look carefully at the minutiae of how I program. I call this variable "i", but why? What do I intend in this case? How will someone understand "i" when they read it later? Sometimes as a result I would decide "i" was a perfectly good name, sometimes I would find a more communicative name ("i" is a good choice for loop indexes and little else).
Coding this way drove me nuts for a while, because I'd code for 10 seconds and then spend an hour ruminating. However, after a couple of weeks I was revisiting already-examined decisions and the second (third, fourth, ...) time through went much faster than it had before because I had settled my constant internal debate about my overall approach and I could just code. The result was more communicative code written faster.
Kent Beck Three Rivers Institute
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007434/ref=jranch-20" target="_blank" rel="nofollow">JUnit Pocket Guide</a>