Developers spend most of their time figuring the system out
So, one aspect of this post is: a) a lot of prior work has assumed that &quot;comprehension&quot; and &quot;reading&quot; are the same and b) reading is a bad approach to understanding code.<p>For me, this also calls to mind an old blog post from Peter Seibel about a disconnect where many of us think that we should all be reading code for our own understanding, somewhat like literature, but very few of us do and it rarely yields much. And one of the reasons why it seems that style of reading is ineffective, is that coming to an understanding of code is more like a scientific investigation than just reading prose.<p><a href="http:&#x2F;&#x2F;www.gigamonkeys.com&#x2F;code-reading&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.gigamonkeys.com&#x2F;code-reading&#x2F;</a><p>I agree with that point. I also agree that we need to be able to create tools that deal with software systems more easily.<p>But I also think two other perspectives are important:<p>- One is the historical perspective. The code-base is rarely a coherent whole. Two different areas may accomplish similar things with different tactics. The design of a component may be ill-suited to the way it is now being used. What is an intentional choice, and what is an accident? Which past choices should my current project align with? We typically read the code as it exists currently, and look at specific parts of the history only as a supplement, because even visualizing history is complex. But understanding why choices were made, and in what context, can be critical to knowing which things can now be changed.<p>- The other is that reading code shows us a complex intensional definition, and reading tests gives us a partial view of an extensional definition (in case X we get behavior Y). But to &quot;understand&quot; programs enough to proficiently change them, we have to grokk something like the neighborhood around our current program: How would a given change in the code change the behavior? Being able to interactively change and re-run a program, and compare behavior before and after is in some sense like doing finite difference method differentiation.