Elsewhere on HASTAC, Ashleigh Faith, Christy Pottroff, and Michael Widner take up the question of humanists learning to code in two very helpful posts. In this post, reblogged from www.shakespearevideogame.com, I reflect on how learning to code has impacted my digital and my traditional scholarship.
Earlier this week, I gatecrashed an excellent talk by Nick Montfort, who was visiting Northwestern's Computer Science Colloquium. I recommend cross-disciplinary gatecrashing whenever possible, if only to see what pastries the other folks have. The talk, "Exploratory Programming for the Arts and Humanities," derived from his new book by the same title. I was surrounded by too many witnesses to pocket the sample copy, but based on Montfort's talk and my prolonged peek at the table of contents, I gather it features practical suggestions and even programming exercises for new-to-that-stuff humanists. (NB: Amazon blurb agrees.)
A key takeaway from the talk was Montfort's exhortation that learning to code – actually, really, building computer programs, however simple – is valuable for humanists. Not just digital humanists, who might write about Starry Night turned into a VR diorama or who make a "poetics of computation" or who kludge together a Flash animation data visualization of Shakespeare's body count in six major tragedies (OK that one's mine) ... Montfort argues that learning to code is valuable for all humanists.
When pressed (by me) on "all," he likened a basic understanding of code to learning Portuguese if one wishes to study Augusto Boal. Making clear that comparing natural languages to computer languages is a flawed analogy (why?) Montfort explained that the sheer inescapability of computational thinking in the digital age necessitates a working knowledge of its basic properties.
Fair enough. Anyway, I think the natural language/code analogy is only a little flawed – it helped me get the point. My own advisor used it to convince me to take an entry level programming course when I announced I wanted to assemble a team to build Something Wicked. "I'll never forget this young scholar who put himself forward as an expert on Chekov," he mused. "I asked if he spoke Russian, and he proudly said he'd never even taken a class. He lost all credibility in that moment. Don't be the Chekov scholar who didn't take Russian 101." Consequently, I took Design of Technological Tools for Thinking and Learning (DTTTL), taught by Uri Wilensky.
Thanks to his course design/endless patience, our group of non-CS grad students with zero coding experience learned to build simple programs with Logo and NetLogo. During the course, I also taught myself Scratch, which I used to build the first prototype of Something Wicked. I should point out that Scratch was developed to teach 8th graders how to code, so my achievement was no feat of computational brilliance. Coincidentally, the "mechanics lock" meeting for Something Wicked transpired the day after Montfort's lecture – at this development milestone, a video game's major systems have been created and are more or less playable. Looking for a nice photo op, I asked one of the programmers if he could pull up the screen he sees when he's coding the game, which is built in Unity.
I hadn't peeked behind the programming curtain of Unity for many months. Much earlier this year, emboldened by my Promethean Scratch endeavor and coming up zeroes on finding a game development team, I had determined to download the free Unity engine and build the damn game myself. I knew Logo, after all.
Upon opening Unity, I was reminded of other times I've made unscaffolded leaps in assumed expertise: my handwriting is lovely – surely I spontaneously know calligraphy. (Wrong.) Similarly, since I can walk and I have seen videos of such, I once concluded I could also Rollerblade. (I knocked over three freshmen.) Most outrageously, after learning to change the oil in my car, I decided I'd also replace the carburetor myself. What non-industrious fool would pay to have it done? To their credit, the Pep Boys employees choked back their howling laughter and politely inquired if I owned an engine hoist. (... I do not.)
It was the carburetor moment I remembered most clearly as I flipped through the Unity menus, after spending half an hour figuring out where the menus are. In terms of computer programming, I was quite pleased to feel myself Prometheus, thanks to Logo and Scratch. But I had no desire to become Icarus. I wanted Something Wicked to be built, built well, and built on a short timeline. I would need collaborators who "speak" Unity.
Before I took DTTTL, I did not really understand what code is. "Instructions to the computer?" But who gives them? How does the computer understand them? Where do these instructions go? And what is meant by "instructions" anyway? But as our very Unity-fluent programmer walked me through some of the commands and panels in the above photo, I found myself understanding more than a few words.
It's unlikely that I'll spend the many hours of
frustration experimentation it would take to upskill myself on Unity to the point of building my own Something Wicked, chapter 2. I would rather eat glass work with an experienced team. But thanks to my limited coding experience, I can have a different kind of conversation with CS collaborators. Whether I'm working on a born-digital project like Something Wicked or my mostly non-digital theatre studies dissertation, learning to code has made me more aware of dimensions of scholarship in the digital age such as the non-neutrality of computational systems, the kinds of questions technology can help us answer, and the questions they most certainly cannot.
What do you think? Must all humanists learn to code?