Karl Stolley is an associate professor at Illinois Institute of Technology in Chicago, where he teaches courses on web design and development. He's published a lot of academic stuff on the connections between programming, interface design, and the humanities. Karl also moonlights as a Rails developer and spends a fair amount of time messing around with Node.js, too.
Peter Seibel recently blogged to challenge the idea of reading code for reading’s sake. “Code is not literature and we are not readers,” he concluded. “Rather, interesting pieces of code are specimens and we are naturalists.”
That’s partially true. Interesting pieces of code are specimens. Yanked from their context in programs or frameworks, lines of code become like dead bugs on pins in boxes.
It might be nice to sit around with a snifter of brandy and discuss a dozen lines of code as though they were some exotic insect or even poetry, but few developers can afford that luxury. Developers have jobs to do and problems to solve that are embedded in thousands of lines of supporting code. Often, these lines are built by numerous developers attempting to address a set of problems that evolve unpredictably over time.
But that’s not to say that developers don’t read source code. Reading is actually the first thing that goes into solving most problems. Sometimes it might be necessary to, first, pick apart a stack trace or grep through any log files that might be on hand. But then it’s on to reading the suspect portions of the source code, and the detective work begins.