I read with a specific context/goal in mind.<p>For a new code base, I start off with a high level design and one feature which touches the important parts. May be there is more knowledgeable with codebase around to ask and also decent documentation.<p>If I am in a Lisp like editing language, this [1] tracer is fantastic. Otherwise in non-live languages, I am a dead duck in the circus of breakpoints/debugger to step through the code.<p>You may also have a look at this [2], the author of Coders at Work, Peter Siebel talking about decoding code and from the same book a very interesting discussion on reading code which I have reproduced here.<p>---<p>Seibel: I’m still curious about this split between what people say and what they actually do. Everyone says, “People should read code” but few people seem to actually do it. I’d be surprised if I interviewed a novelist and asked them what the last novel they had read was, and they said, “Oh, I haven’t really read a novel since I was in grad school.” Writers actually read other writers but it doesn’t seem that programmers really do, even though we say we should.
Abelson: Yeah. You’re right. But remember, a lot of times you crud up a program to make it finally work and do all of the things that you need it to do, so there’s a lot of extraneous stuff around there that isn’t the core idea.
Seibel: So basically you’re saying that in the end, most code isn’t worth reading?
Abelson: Or it’s built from an initial plan or some kind of pseudocode. A lot of the code in books, they have some very cleaned-up version that doesn’t do all the stuff it needs to make it work.
Seibel: I’m thinking of the preface to SICP, where it says, “programs must be written for people to read and only incidentally for machines to execute.” But it seems the reality you just described is that in fact, most programs are written for machines to execute and only incidentally, if at all, for people to read.
Abelson: Well, I think they start out for people to read, because there’s some idea there. You explain stuff. That’s a little bit of what we have in the book. There are some fairly significant programs in the book, like the compiler. And that’s partly because we think the easiest way to explain what it’s doing is to express that in code.<p>---<p>Overall, I try to read in small pieces with some clear goal. Interestingly enough, I don't know if we can read code from start to end like a book, may be literate programming makes that possible; but yes reading code is hard and that is simply because we don't have good code reading tools, yet in the 21st century!<p>[1] <a href="https://www.cs.cmu.edu/~dst/Lisp/dtrace/dtrace.generic" rel="nofollow">https://www.cs.cmu.edu/~dst/Lisp/dtrace/dtrace.generic</a><p>[2] <a href="http://www.gigamonkeys.com/code-reading/" rel="nofollow">http://www.gigamonkeys.com/code-reading/</a><p>EDIT: link to the code is not literature article