Sign in or register
for additional privileges

Border Codes

Mark Marino, Author
Previous page on path     Next page on path

 

You appear to be using an older verion of Internet Explorer. For the best experience please upgrade your IE version or switch to a another web browser.

Annotating Code -- Programmer Interviews

Code has a unique relationship to the issue of intentionality. Colloquially, we refer to a person who means what they say and also about performative language, as theorized by J.L. Austin, utterances which perform actions, as in the "I now pronounce you husband and wife" of the wedding ceremony.   Yet even that formulation loses its empirical qualities its universal communication power -- like a light switch -- when the wedding ceremony involves two men or two women.   

However, in the world of computer programs language has that light-switch quality.  Once translated into machine language, code truly seems to "do," seems to cause actions to occur.  Except when it doesn't, as in the case of a statement with incorrect syntax or that is not being processed in a predictable way by other bodies of code. 

This act of predicting the way code will operate is central to the activities of the programmer and failure to do so correctly is responsible for countless hours of misery on the part of programmers hunting for "bugs" and other assorted errors and oversights.   

As a result, even though readers of code do not have to worry about the intended meaning of code, intentionality is not so easily dealt with as it has been in the past decades of literary criticism, for example, where the author's intention is only one framework for interpretation.   In the case of code, as the discussion from the second week of the Critical Code Studies Working Group makes clear, "intended effect"  is a key axes for understanding the nature of the code and its functioning.

Because of this more central role of intention and because of the contingency of meaning in general, interviews with the authors and developers of the code offer a rich vein of insight into any critical code reading. "Authoring" may not be the right word for this activity at all, which can involve oversight and quite a bit of re-use of code.  Perhaps other terms will soon replace it, one that evokes a sense of pastiche, assemblage, such as bricoleur or even mason.




Comment on this page
 

Discussion of "Annotating Code -- Programmer Interviews"

Add your voice to this discussion.

Checking your signed in status ...

Previous page on path Typology of Annotations, page 1 of 5 Next page on path