> > I got a copy of the source-code listing for it. I didn’t have a manual for the machine, so I wasn’t even sure what the machine language was. […] It was just basically the way you solve some kind of an unknown puzzle—make tables and charts and get a little more information here and make a hypothesis. In general when I’m reading a technical paper, it’s the same challenge. I’m trying to get into the author’s mind, trying to figure out what the concept is. The more you learn to read other people’s stuff, the more able you are to invent your own in the future, it seems to me.
> He’s not describing reading literature; he’s describing a scientific investigation.
So when people like Knuth talk about “reading code”, or even reading papers or books!, they're already describing a process like what you described, not reading linearly.
Even for his “literate program” TeX, you can see (https://www.youtube.com/playlist?list=PL5B7B2302476634D5 1:08:25 in session 4) that he recommends reading it that way:
> Start at the beginning, read some of these comments and familiarize yourself with use of the index, and then set yourself some problem or other. […] If you take any one of TeX’s primitives like “def” or something like that, you can look it up in the index under that name and it will say “def primitive” and it will refer you to the place where it was put in the hash table and that will refer you to what command code it has and you might be able to trace through looking at the index [the] whole history of def, how it comes through TeX. If you don’t like that problem, give yourself some other little task, saying “I wonder what this does” and that will just give you a reason for perusing the index and finding your way through the report… the main thing to do is just to get a little familiar with the notation and mess up the page—get the page a little black on the edges.