I’m giving two very short presentations at Computers & Writing 2011, since I’m part of two roundtables: the first Town Hall (Friday at 8:30am) and “Is Blogging Dead?” during Saturday’s E session (also 8:30am). I like giving short talks, so this is fine with me: all told, I’ll be speaking about eight minutes. Short on theory and details? Maybe. But that’s what discussion is for.
So (after the jump), here’s the first one, for the town hall: “More code please, we’re geeks!” In which I argue that we’ve got to keep working with code, and suggest a framework for doing so.
Some my first involvement in Computers & Writing was engagement in email discussions, or maybe I should say holy wars, about the way we should approach web authoring. The TechRhet list returned to this topic in February 2011. I don’t want to reopen those holy wars today — at least not directly — since I agree with those who wrote in February: code wins. Sure, we probably aren’t opening Textpad and typing <html> <head> <title> anymore; but we are and should be engaging code directly. As Karl Stolley suggested: nobody is arguing against learning code in writing, but lots of people are doing just that in practice.
So if we have a theory-practice gap, then what? We need a framework for engaging code.
In an essay I wrote with Jeff Rice, we point out that unlike print, the web doesn’t hide its markup. Marshall McLuhan said that was a characteristic of type. As he wrote, “Typographic man can express but is helpless to read the configurations of print technology.” But we don’t live in a solely typographic world any more. Our world is configured of code we can express and read: markup and other kinds. And this code is available via View Source, through cut and paste code made available for embedding, and infrastructures designed for reapplication.
I borrow the way forward for us, then, from McLuhan, in three parts: reading, expressing, and configuring code.
Reading code means language awareness — knowing how to read code, and where to find it, but also the different forms it comes in. We think first about markup and source code, but we need to consider standards, specificiations, documentation, APIs, and other texts which supplement code. In fact, much of code reading is these related texts. We know from Agile development that when writing, we need to keep pushing software out the door, rather than obsess over these supporting texts. However, as we learn and teach, they can be a focus. So we need to pay attention to associated reading, developer tool kits and frameworks, as well as what might be called “the code itself.”
Expressing code means writing code and sharing it. More to that, it means not avoiding code. The big advantage we have now over ten or even five years ago is tools which allow us to build, test, and distribute software very easily. AppMaker, Google Docs, WordPress, and a host of other software is built with this platform architecture in mind. For example, I used Delicious to build an annotated index of course readings. Derek Mueller used the Google Docs API to build writing center scheduling software. I could mention many more interesting projects which leverage a small amount of coding knowledge for large results. Here’s the payoff: expression means working with the smallest bits of code possible. Experimenting with uses of hashtags or at-handles on Twitter. These small expressions offer low barriers not only for doing, but for discussion too.
Configuring code means understanding its social, mental, and physical infrastructures. How does code fit into larger systems? How does it function as writing? Here two focuses are necessary: transfer and sustainability. We must ask ourselves, what am I doing to allow connections with other contexts, both in terms of learning and general engagement? Kristin Arola’s work with templates comes to mind here: are we approaching with templating in general, or only in connection with a specific use — say, adapting WordPress as a low-end CMS for a community literacy organization? We need to explicitly address these movements from general to specific in research, experimentation, and teaching. What can be carried to other contexts from our work? How much energy will be required to adapt this code? to maintain it? to improve it?
And as you can tell from the overlap here: we are much better equipped to do any of these things when we do all three of them. The engine for learning code is comparison, and we should engage it as often as possible. Here the old model works: hack, view source, hack, test, repeat.
I’m happy to talk more about any of these ideas in our discussion. Thanks.
Edit 5/20: I forgot to post the slide deck for this talk.