My friend Liz Losh, regarding code literary for those in the humanities:
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?”
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.
permalink |