Recently, I have been receiving lots of love letters from Python, full of emotional language like the following:
Can you imagine my excitement? No? Okay, let me give a little background. I am collecting and analyzing large amounts of Twitter data for both my work in the DWRL and a little dissertation I’m trying to write on the side.
Having done only relatively basic programming before, anything much more advanced than ‘count how many times the words “one more time” occur in Daft Punk’s One More Time’ involves a learning curve for me. The process has a lot of potential for failure and frustration, as embodied in the error message above.

This is a good chance to reflect on the novice coding experience and its relationship to rhetoric and pedagogy.
If we compare a block of code with an argument made in a student research paper, Python (or any other language) turns into the reader that evaluates that particular argument. The good thing is that it actually responds, either by executing the code (whether in the ay you intended to or not) or by telling you that there is a problem.
And not only does it tell you THAT there is a problem; it at least makes an attempt to locate that problem for you. So, in the example above, the error message tells me that line 13 in the my script “TimeZones3.py” is running into trouble, and more specifically, that the 2294th character in the first line of the document it is trying to process is causing that trouble because it is an “invalid control character.”
I did not realize you had to zip the bag in order for the food to stay fresh. #instructionsunclear
— George Lam, Esq. (@georgelamb) September 29, 2015
The process of debugging can then be as straightforward as changing the “ in line 1 to a ‘. But more often than not, it will be an incremental chase across different variables. In any block of code, elements depend on other elements and the one line that is raising an error may not be the one that ultimately causes the problem.
https://twitter.com/CatsVansBags/status/648625693618761729
So, dealing with faulty code can teach several important aspects of rhetoric and composition, such as:

- There is a reader/interpreter at the other end of the communicative event. (This seems common sense enough, but sometimes gets obfuscated in traditional classroom settings.)
- If something is not working in a given paper, that does not have to do with that paper being “bad” or the author “being good at writing” in general. Instead, the problem can and should be attributed to a specific disconnect in the argument, e.g. a logical fallacy, a misreading of the audience or context, etc.
- Just as debugging involves tracing how different elements of code relate to each other, writing can be deconstructed into different premises that lead to conclusions, which in turn can combine to lead to further conclusions.
Nearly ten years ago now, Robert E. Cummings argued for “repositioning the rhetorical triangle as a coding triangle” and for incorporating computer programming into pedagogical practice. For all
instructors toying with this idea, the article gives some concrete suggestions on how to put it into practice.
Or, if you are an instructor who has actually worked with coding in the classroom, the comments section would be a great place to share your experience. Digital technology has become both more ubiquitous and has striven to be more and more invisible since 2006, doubtless changing the way users relate to and are configured by it. It would be revealing to hear which of Cummings’ observations still hold in 2015, and what has changed in ways that might then have been unpredictable.

Finally, if you want to get really theoretical, rhetorical engagement with error messages and glitches can be taken much further than the basic idea presented here. Casey Boyle, assistant professor in rhetoric and writing here at UT, has a recent paper out that explores glitch through the concept of “metastable orientation.” To oversimplify: beyond making technology (and writing) transparent, glitch casts relations between (or with, against, etc.) hardware, software, and human users that precede subject and object positions and out of which these positions continually emerge.
Featured Image Credit:
AA Breakdown Service by AASouthAfrica, retrieved from Wikimedia Commons.