Program or Be Programmed: Computers and Writing 2012 Town Hall 2
The central concept of this panel “Program or Be Programmed” might immediately bring up performance anxiety issues for many people in this audience. As Stephen Ramsay put it recently, the very notion of the tech-savvy digital humanities as the newest “hot thing” tends to bring up “terrible, soul-crushing anxiety about peoples’ place in the world.” For those in composition, the anxiety might be even more acutely soul-crushing in light of existing labor politics. Every time the subject of learning code comes up, one can almost see the thought balloons appearing: “How can I learn Python in my spare time when I can’t even see over the top of the stack of first-year papers that I have to grade?” And for those who care about inclusion, what does it mean to choose the paradigm of computer programming culture, where women and people of color so frequently feel marginalized? Furthermore, if all these powerful feelings are being stirred up, what questions should we be asking about ideology as an object of study. For example, Wendy Chun has argued that a desire for mastery over blackboxed systems or access to originary source code shows how a particular dialectic of freedom and control makes it difficult for us to have meaningful discussions about technology and to acknowledge our own limited access to totalizing understanding, even if you are a software engineer.
Fortunately, after hearing these talks, people in the audience should feel a little less anxious. They should know that doing-it-yourself means doing-it-with-others, whether it is imagining Picasso and Braque building a flying machine, as David Rieder suggests, or installing Ubuntu with the help of a neighbor, as Alexandria Lockett describes. The message to instructors in this panel is comforting: relax, be confident in your own abilities to learn new things, ask questions, facilitate the questions of others, and network in ways that help you make new friends.
However, if you are an administrator as well as an instructor, don’t get too relaxed just yet. These talks also bring up some very thorny questions about disciplinary turf. After all, who defines how digital literacy should be taught and who will teach it? Computer scientists? Media artists? Librarians? Us?
Although he uses the word “craft,” Karl Stolley asserts that “source literacy” doesn’t require an elaborate apprenticeship. All it takes is moving toward a set of everyday common-sense practices involving command lines and file structures. Mark Sample suggests the term “code competency” as an alternative to “code literacy,” because of all the cultural baggage associated with the word “literacy” itself. Trebor Scholz has suggested “fluency” as a better characterization of what we are trying to teach, but Sample notes the limitations of that term.
In a 2010 essay called “Whose Literacy Is It Anyway?” Jonathan Alexander and I pointed to Michael Mateas’s work on “procedural literacy” as a way for compositionists to begin to engage with these issues. Mateas worries that universities are often too eager to adopt the training regimes of computer science departments, which is great for graduating computer science majors but not so great for teaching students in other majors or with other passions to use code. So what should be the relationship between writing studies and computer science in the academy?
People at this conference are probably more likely to be able to say that line about “some-of-my-best-friends-are-computer-scientists” than those at the MLA. (I personally carpooled with computer science faculty for ten years when I worked at UC Irvine and learned something about discrete math and number theory in the process.) But what does that collegiality get us? Both Sample and Vee mention Edsger Dijkstra, who was also the author of “On the Cruelty of Really Teaching Computer Science,” a decidedly anti-humanistic diatribe on the superiority of formal logic and mathematics as the keys to supposedly real knowledge.
Given the fact that badly written code can overdose patients with radiation or knock out someone’s retirement savings, I’m not sure that I always agree with Vee that clean, legible, rationalized code is not worth teaching to everyone, but I’ll put in my own GOTO command for writing studies to keep this spaghetti-like discussion going with our colleagues elsewhere long after this panel concludes.
Fortunately, after hearing these talks, people in the audience should feel a little less anxious. They should know that doing-it-yourself means doing-it-with-others, whether it is imagining Picasso and Braque building a flying machine, as David Rieder suggests, or installing Ubuntu with the help of a neighbor, as Alexandria Lockett describes. The message to instructors in this panel is comforting: relax, be confident in your own abilities to learn new things, ask questions, facilitate the questions of others, and network in ways that help you make new friends.
However, if you are an administrator as well as an instructor, don’t get too relaxed just yet. These talks also bring up some very thorny questions about disciplinary turf. After all, who defines how digital literacy should be taught and who will teach it? Computer scientists? Media artists? Librarians? Us?
Although he uses the word “craft,” Karl Stolley asserts that “source literacy” doesn’t require an elaborate apprenticeship. All it takes is moving toward a set of everyday common-sense practices involving command lines and file structures. Mark Sample suggests the term “code competency” as an alternative to “code literacy,” because of all the cultural baggage associated with the word “literacy” itself. Trebor Scholz has suggested “fluency” as a better characterization of what we are trying to teach, but Sample notes the limitations of that term.
In a 2010 essay called “Whose Literacy Is It Anyway?” Jonathan Alexander and I pointed to Michael Mateas’s work on “procedural literacy” as a way for compositionists to begin to engage with these issues. Mateas worries that universities are often too eager to adopt the training regimes of computer science departments, which is great for graduating computer science majors but not so great for teaching students in other majors or with other passions to use code. So what should be the relationship between writing studies and computer science in the academy?
People at this conference are probably more likely to be able to say that line about “some-of-my-best-friends-are-computer-scientists” than those at the MLA. (I personally carpooled with computer science faculty for ten years when I worked at UC Irvine and learned something about discrete math and number theory in the process.) But what does that collegiality get us? Both Sample and Vee mention Edsger Dijkstra, who was also the author of “On the Cruelty of Really Teaching Computer Science,” a decidedly anti-humanistic diatribe on the superiority of formal logic and mathematics as the keys to supposedly real knowledge.
Given the fact that badly written code can overdose patients with radiation or knock out someone’s retirement savings, I’m not sure that I always agree with Vee that clean, legible, rationalized code is not worth teaching to everyone, but I’ll put in my own GOTO command for writing studies to keep this spaghetti-like discussion going with our colleagues elsewhere long after this panel concludes.
Labels: conferences
posted by Liz Losh at 12:45 PM
1 comments
