Code is not Literature

I think the author has a somewhat limited definition of “literature”, though he ultimately comes to the right conclusion that code must be “studied”, not “read”. It’s true, code is typically less linear than a pulp novel, but other types of literature are also involved, with layered meanings, which must be examined carefully, with reference material handy, and lots of flipping back and forth between sections. For instance, poems, philosophical treatises, historical analyses, and math textbooks must all typically be read this way.

"Once I’ve completely rewritten the thing I usually understand it pretty well and can even go back to the original and understand it too. I have always felt kind of bad about this approach to code reading but it's the only thing that's ever worked for me."

This strategy may work for small programs, but it doesn't scale to large programs. For example, most people aren't going to have the time to refactor Firefox or the Linux kernel to figure out how they work.

Also, it's hard to tell a lot about a large program just by reading a listing of the source code. Certain things about the code become much more obvious if you step through the running code with a debugger. To extend the author's analogy of a program being a scientific specimen: the code is a living specimen whose behavior can be studied, not just a dead specimen that can be stained and looked at under a microscope.

Seems like a worse metaphor to me, naturalists don't examine specimens in order to learn how to make better animals but that's precisely the reason coders are expected to improve by reading code (although I always assumed that "reading code" meant reading it over and over to get a detailed understanding but apparently that was just me?).

What is the goal of reading literature we're talking about? We're mixing up reading a book for pleasure and gaining a deep understanding of a piece of literature to become a better writer.

Reading a piece of code or a book once is not going to do anything to your skillset as a producer, at least books are specifically written to be read once for pleasure. The equivalent for code would be using a piece of software, not reading the code once.

If you want to be a better writer then you get a deep understanding of a piece of literature, the same applies to code. I have recently read a lot of code, because I was debugging/modifying a library I was using (the Requests lib in Python). It's very nicely written and I did get some good ideas from it, but it was work.

I don't think the metaphor is flawed at all. I think that this was a result of coders thinking that people would get better at writing by reading literature or that this was the point of literature seminars. I guess a lesson in understanding other disciplines at least a little bit before trying to take lessons from them?

> Because we're stuck in a tyranny of flat text files as a representation of code.

Their simplicity is also a strength. That richer file format will at some point be written in a text file.

As someone who also tried to hold code reading groups I agree 100% with the conclusion.

The first code reading session I held, I chose underscore.js and it was a successful code reading session, because -- unlike most libraries and programs -- a functional utility library was a nice linear read with mostly self-contained functions. However, when we got to more complex programs and libraries with more code to handle accidental complexity (e.g. handle browser and DOM inconsistencies, or UNIX fragmentation etc) it was considerably harder to read and the presenter found themselves jumping between different code paths and functions like they were debugging the program.