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:
One needn't spend years or even months gaining a basic literacy with code --- in reality, the basics of most computer languages can be learned relatively quickly, in hours or days. What's less easy to obtain is a feel for software architecture, the properties of algorithms, the strangely brittle, powerful, frustrating, and liberating qualities of software engineering, the subtle relationship between design, human unpredictability (we build software for human use, in the context of a social, biological, and economic ecosystem), the ways in which people constantly surprise creators of software, the unpredictable nature of the cycle of design-build-observe-redesign... the many techniques people have attempted to employ to get a handle on these dynamics... all of this goes far beyond the confines of learning code, but are actually, I think, if anything more important for a critical engagement with technology. To get a feel for coding, I'd recommend trying something like Processing or, for the more adventurous, trying to build a simple site using one of the many Rails tutorials. However, after that, I'd stop --- and go read a book like Design Patterns, which takes its inspiration from the work of the great architect Christopher Alexander. Then go read up on user experience design, starting with user-centered design up to more current iterative development approaches, and research development methodologies such as waterfall and agile approaches. Getting a grip on some of these subjects would, I think, be far more valuable in terms of understanding the nature of how software is built both today and in the past, how it might be built in the future, and the ways in which software development has gone far beyond the confines of a purely mathematical or engineering discipline to being a discipline which by its very nature has to include many other disciplines within it, ranging from visual design to sociology to aesthetics to ethnology to psychology to statistical analysis to economics --- a sense for all this has become essential to developing software, yet at the same time there is a strong need for more and better critical understanding of the larger-scale effects of technology on/in the world. Despite all the sophistication of both the technology and many of the methodologies, there remains a curious naivete, in my view, among many who practice in the field, regarding the sociopolitical, economic, and social implications of technology.
Post a Comment
<< Home