Max's comment:

I’m particularly intrigued by the question of how one’s choice of environment influences the code readings. The environment that seems most obvious to me is the text-based source code editor, like Notepad++ or TextPad. These sorts of static, text-based environments are naturally some of the best places to produce code, although I can envision more fluid environments in which programmers can input code with movements other than keystrokes (I’m thinking specifically about non-text-based iPad development platforms, though I don’t know if such things exist). My specific concern is whether the code production environment necessarily dictates what the code reading environment should look like. I’m inclined to think that this is not the case. I think code can be written in one locale, and analyzed in another. Moreover, I believe it is crucial for CCS practitioners to examine code from myriad distinct places, so as to garner an especially rich collection of perspectives on what the code does. So then the question becomes this: what environments can we use to look at code?

The search for appropriate ‘reading environments,’ if you will, probably hinges largely on the specifics of the program at hand, which will clearly be variable from one piece of software to the next. For example, a mobile application will necessarily require a reading approach that differs significantly from a desktop application. Maybe the particular layout of the phone’s input devices (eg. buttons, the presence of a GPS device or gyroscope, et cetera) will lend itself to a reading that focuses on human interaction with handheld devices, or something along those lines. Or maybe a piece of software designed for a satellite or space shuttle will feature various components not found in other kinds of computers. Despite the virtually unlimited number of possible reading environments, I would venture to suggest that there may be some standard places for us to start.

One of the environments I have in mind is the debugger. For those not familiar with the role of a debugger, it’s essentially a tool that allows software developers to test out their program and look for any kinks as it runs. At the CCS conference at USC, which took place over the summer of 2010, I presented a paper in which I discuss the benefits of performing critical code readings with a debugger. I borrowed an idea from Wendy Chun’s manuscript Programmed Visions: Software and Memory to create the framework for my interrogation of debuggers: Dr. Chun scrutinizes the relationship between instruction and execution. She remarks on how these two entities simultaneously conflate and separate, in history and in theory. I extend this idea (or at least explicate what she has implied) to include the interaction of instruction and execution as a piece of software runs. I then proceeded to examine the relationship of these two entities in a piece of artificial intelligence software called Soar. At the end of the paper, I conclude that the debugger serves as an example of how a multifaceted approach to CCS can help produce an interesting reading (at least, I thought so :).

I’m curious to know: what other environments would be useful for performing critical code readings? How much mileage could we get out of something like a hex editor to look at closed-source software? Are there other kinds of diagnostic tools that we can explore? One great example comes courtesy of Stephen Ramsay in his terrific "live reading" video, Algorithms are Thoughts, Chainsaws are Tools.

I imagine that seasoned programmers or especially creative non-coders might be especially able to shed light on various coding (or testing, or run-time) environments that may also serve as useful reading environments.