"Everyone's a Coder Now": a presentation at 4Cs

A couple weeks ago I presented at the 4Cs (Conference on College Composition and Communication) as part of Session H18: “Writing text, writing code, writing connections”. My co-panelists were the lovely and talented Annette Vee and Brian Ballentine, and the panel was chaired by the inimitable Dennis Jerz. We had a good turnout—something like 25 people, and not all of them were our close personal friends (!!).

Here’s the panel intro:

An underacknowledged relation of composition and rhetoric is code studies, the critical examination of source code that comprises computer software. Yet the expertise we have in pedagogy, rhetoric, speech acts and narrative offer potential contributions to this new field. This panel plumbs the connections between two important means of communication—written text and written code—to update our understandings of composing with computers. We map productive inroads to code studies by way of rhetoric, Speech Act Theory and narrative theory and collectively argue that code is already central to the discipline of composition and rhetoric.

Here’s the abstract for my part (I was first up):

A guiding question during the Spring 2010 meeting of the Critical Code Studies Working Group was “who reads code?” Although a simple question, it implies that code is read by people and not only the machines that compile and execute such source material. In this meeting, Jeremy Douglass enumerated the “real code readers” of the world, a list that included mathematicians who read code for its beauty, craftsmen who read code for its elegance, hackers who read code to deduce an exploit, customers reading code to make a purchase decision, and codewriting students attempting to learn to think and act (code) differently. In short, everyone reads code because code is all around us–source code written and read by humans becomes compiled code executed by machines, which in turn powers the “technical code,” or what Andrew Feenberg defines in Alternative Modernity as the “unexamined cultural assumptions literally designed into the technology itself” (87). In this presentation, Speaker 1 [that’s me] provides a brief overview of the work of the Critical Code Studies Working Group and examples in which everyone reads and writes code—knowingly or not—in our lives and work. For instance, social networking sites such as Facebook force millions of users into highly structured templates intended to feed information back into the machine (and, by extension, the corporation), while purportedly offering a free and open site of play and expression within a customized, individual virtual community. The necessity of understanding the rhetoric of the code that shapes the systems in which we (and our students) are embedded thus becomes clear; Speaker 1 [still me] will then describe a few methods for supporting student understanding of the function and limits of their own rhetorical choices within code production.

Here are the slides! (view at slideshare.net if they don’t appear below)

I didn’t really do all that I said I would do in my abstract; I stopped after giving an overview, making a penis joke (it was related, I swear…), and framing more than a few things from the point of view of the programmer (me)—one that emphasized the “programmer’s objection” that I discussed as part of the overview of the field as it is. This was the only panel at 4Cs that talked about critical code studies in any way (that I could tell from a read through the program), and I figured an overview would be adequate. The slide at the end, about “continuing arguments,” points specifically to what my co-panelists were discussing.

During the Q&A period at the end, I talked briefly about the concepts of epics, stories, and bugs in software development (and the writing thereof), and how these are ways that students/newbies to programming could begin to involve themselves in the narratives of code without actually (yet) coding. An epic is a long story that can be broken into several smaller stories—and typically aren’t able to be broken into smaller (more defined) pieces at time of writing/exposure to the development team. Stories or user stories are those specific requirements expressed in non-technical language. These are common in Agile (or trying to be Agile) software development projects.

Another interesting place of intersection is the Given/When/Then syntax of requirements-writing in behavior-driven development. Something like Cucumber (“behaviour driven development with elegance and joy”) can help introduce a non-programmer into a development environment, then lead them toward actual programming (in a language like Ruby) instead of blindly copying someone else’s code, changing a few things, and calling it good.