Reading will always be hard. Always. When we read books, we don’t notice just how damn hard it is because we are reading at such a high level. For example, when I read a classic novel, I think of themes and motifs on a broad scale. I completely miss most details in the phrasing, and you can forget about obscure literary references. I’m not intentionally skipping over these things. I’m not reading as if every sentence matters.

It takes a seasoned literature veteran to extract the detail work from novels that were written by seasoned veterans. To the rest of us, “Moby Dick” may as well be “Snow Crash”.

Code is different. Every line has important details that are needed to understand what is going on. Code must be read closer than you’ve ever read a novel, and that level of tedium is just too much for some. As Joel Spolsky puts it in his post “Things You Should Never Do, Part I“:

There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.

The Solution

So how do we deal with the tedious task of reading code? By reading code. As with all things, the more you work at it, the better you will get at it. Don’t shy away from a code example just because it is written in another language. Pull out the reference and get yourself learning. It can only help you in the end.

As with all things, practice doesn’t work if you don’t practice the right way. Many of us have been exposed to reading comprehension techniques along the way. There are many different ways to go about this process, but I’ll stick with the mythical Levels of Reading Comprehension.

Levels of Reading Comprehension

• Level Zero: Don’t read the text, and form a strong opinion from the title (reserved for advanced Internet users and high school dropouts).
• Level One: Literal.
• Level Two: Interpretive.
• Level Three: Applied.

The Level One details for code are the implementation details: “what is the interface?” “What language is it written in?” “What data structures are being utilized?” Piecing together all Level One information on a piece of code essentially outlines the algorithm, much as having all Level One information on a book gives you the plot. You can essentially view this as the quantitative information that the code has to provide.

On the other hand, Level Two questions are where you begin to judge the qualitative nature of the code. “Why was this algorithm chosen?” “What tradeoffs were made in this design?” “Is there a way that this could be done more efficiently?” “Could a different data structure have been used?”

Writing is also hard, and you’ll find plenty of instances where the authors come up short. The burden is on you to prove beyond a shadow of a doubt that you’re right and the author is wrong. If you’re not bending over backwards to try to say “well, maybe the author was using it in the context of..”, you’re not giving them much credit, and might not be putting enough thought into the process. When you find yourself saying “this code is awful!”, try thinking of how you would do it yourself. Sometimes you find that you come up with a better way than the author. Sometimes you’re led right back to the same solution as the author.

Level Three is where we can find the strongest lessons, and ask the deepest questions. When can I use this algorithm? When should I modify it? Why should this implementation be obvious, given the problem description?

This is where a programmer’s critical thinking skills will shine.

Granted, it’s difficult to determine the ramifications of question such as, “What would the impact of using this non-standard syntax be if I made 300,000 library users adopt it?”. However, thinking on such a big scale can only help you as a programmer, and the bigger you think, the more you help yourself.

Other Examples

There is a lot of precedent in the Maths and Sciences to use this kind of Level Three critical thinking. To list a few examples, in “You and Your Research“, Richard Hamming (after whom half of the natural world is named) goes into great detail about how the aspiring researcher should arrange his or her thoughts in order to produce great research. He decides that only by setting aside time to ask yourself deep, analytical, important thoughts can you ever produce great things.

In “A Short Talk about Richard Feynman“, Stephen Wolfram notes:

“But wherever one could go with that, Feynman could go. Like no one else.

I always found it incredible. He would start with some problem, and fill up pages with calculations. And at the end of it, he would actually get the right answer!

But he usually wasn’t satisfied with that. Once he’d got the answer, he’d go back and try to figure out why it was obvious.”

And often he’d come up with one of those classic Feynman straightforward-sounding explanations. And he’d never tell people about all the calculations behind it. Sometimes it was kind of a game for him: having people be flabbergasted by his seemingly instant physical intuition. Not knowing that really it was based on some long, hard calculation he’d done.

He always had a fantastic formal intuition about the innards of his calculations. Knowing what kind of result some integral should have, whether some special case should matter, and so on.

And he was always trying to sharpen his intuition.”

Granted, Feynman and Hamming weren’t reading the work of others, they were interpreting their own work. However, programming provides plenty of opportunities to ask yourself these kind of deep analytical questions. You just need to know the right questions to ask.