[greenyoda]

"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.

[skybrian]

That's a good point about running it in the debugger.

However, even with a large program, sometimes I find it helpful to write a smaller program that does much the same thing as a small part of it. For example, last year I wrote a debugger frontend in Dart, based on the Chrome DevTools debugger. Whenever I wanted to implement something I'd first look at how the Chrome debugger did it.

Currently I'm working on a reimplementation of the React framework, also in Dart.