David Rieder (with a little help from me) organized a Town Hall focused on programming at the Computers and Writing conference at North Carolina State University this last week (May 19). The topic was: “Program or be Programmed: Do We Need Computational Literacy in Computers and Writing?” and the panelists were David Rieder, me, Mark Sample, Alexandria Lockett, Karl Stolley, and Liz Losh as respondent.
From the questions, twitter backchannel [edit: see Mark Sample’s backchannel archive of #cwcon], and comments I got from the audience after the Town Hall, it appears to have been a success. For those not already thinking about this question, we got people thinking about it. For those already thinking about this question (which was most of the audience, I think), we said some controversial things, anxiety-producing things, and some things that elicited lots of head-nods.
I’ve pasted my comments on “Coding Values” below. You can find the text of the other panelists’ comments here:
- David Rieder’s “Programming is the New Ground of Writing” [pdf]
- Mark Sample’s “5 BASIC statements on computational literacy“
- Alexandria Lockett’s “I am not a Programmer“
- Karl Stolley’s “Source Literacy: A Vision of Craft“
- Liz Losh’s response
Today I want to talk about good code. Experienced programmers often think about what good code is. But they rarely agree.
And here’s what I want to say: they don’t agree on what good code is because there is no good code. Or, rather, there is no Platonic Ideal of Good Code. Like writing, there is no good code without context.
Unfortunately, when good code is talked about, it is often talked about as if there’s no rhetorical dimension to code. It’s talked about as though the context of software engineering were the only context in which anyone could ever write code. As if digital humanists, biologists, web hackers, and sociologists couldn’t possibly bring their own values to code.
I’ll give you just a couple of examples of how this happens, and what this means for us in computers and writing.
One of the earlier articulations of the supposed Platonic Ideal of Good Code was Edsger Dijkstra’s infamous “GOTO considered harmful” dictum, from 1968.
This article railed against unstructured programming and the GOTO command. Now, many of us first learned the joy of coding through the languages that used the GOTO command. But Dijkstra’s statement suggests that the context of the software engineering work place should override all other possible values for code. This is fine—as far as it goes, which is software engineering and computer science. But this kind of statement of values is often taken outside of those contexts and applied in other places where code operates. When that happens, the values of hacking for fun or for other fields are devalued in favor instead of the best practices of software engineering—that is, proper planning, careful modularity, and unit testing.
Ender7 is replying here to a thread about a recent ScientificAmerican story that suggested scientists were reluctant to release the code they used to reach their conclusions, in part because they were “embarrassed by the ‘ugly’ code they write for their own research.” According to Ender7, they *should* be ashamed of their code. Ender7 goes on to say:
Why is academic code an “unmitigated nightmare” to Ender7? Because it’s not properly following the rules of software engineering. Again, the rules of software engineering presumably work well for them. I’m not qualified to comment on that. But that doesn’t mean that those values work for other contexts as well, such as biology.
So, in this example, software engineering’s values of modularity, security, and maintainability might be completely irrelevant to the scientist writing code for an experiment. If scientists take care to accommodate these irrelevant values, they may never finish the experiment, and therefore never contribute to the knowledgebase of their own field. The question, then, isn’t about having good values in code; it’s about which values matter.
We often hear how important it is to have proper grammar and good writing skills, as if these practices had no rhetorical dimension, as if they existed in a right or wrong space. But we know from writing studies that context matters.
Put another way: like grammar, code is also rhetorical. What is good code and what is bad code should be based on the context in which the code operates. Just as rhetorical concepts of grammar and writing help us to think about the different exigencies and contexts of different populations of writers, a rhetorical concept of code can help us think about the different values for code and different kinds of coders.
And this is how coding values are relevant to us in computers and writing. The contingencies and contexts for what constitutes good code isn’t always apparent to someone just beginning to learn to code, in part because the voices of people like Ender7 can be so loud and so insistent. We know from studies on teaching grammar and writing that the overcorrective tyranny of the red pen can shut writers down. Empirical studies indicate it’s no different with code. Sure there are certain ways of writing code that won’t properly communicate with the computer. But circle of valid expressions for the computer is much, much larger than Ender7 or Dijkstra insist upon.
To close, I want to share with you a bit of what might be considered very ugly code, a small Logo program I call, tongue-in-cheek, “codewell”:
This is bad code because:
- it is uncommented and hard to read
- it’s in an old, seldom-used language
- it is baggy and has repeated statements that should be rewritten as functions
- it is not modular or reusable
- it’s an “unmitigated nightmare”
- it could be used to teach people some things about functions and code
- it’s a start for a LOGO library of letters that might be kindof cool
- it does what I want it to do, namely, make my argument in code form.
Let’s imagine a world where coding is more accessible, where more people are able to use code to contribute to public discourse or solve their own problems, or just say what they want to say. For that to happen, we need to widen the values associated with the practice of coding. To Edsger Dijkstra, I’d say: coding values that ignore rhetorical contexts and insist on inflexible best practices or platonic ideals of code should be CONSIDERED HARMFUL – at least to computers and writing.