Hacking the Classroom

Eight Perspectives

Mary Hocks and Jentery Sayers


At the 2012 Computers and Writing conference, a panel of academics came together and embarked upon a series of lighting round talks, broadly focused on the topic, "Hacking the Classroom." The organizers, Virginia Kuhn and Jentery Sayers, chose this topic because it resonates with the growing practice of hacking academia by turning the critical gaze inward, rethinking institutional structures and practices, and revising them to foster new social relationships, pedagogies, and modes of inquiry.

With hacking in mind, the panelists—who hailed from disparate institutions, professional positions, and disciplines—engaged the following questions: When, where, and why do classrooms in higher ed need to be hacked? How might we hack them? And under what assumptions?

Each panelist provided particular examples of their own hacking practices as well as aspirations to hack the classroom at their respective institutions, while addressing some obstacles, enthusiasms, and curiosities encountered along the way (including the panelists' own skepticism about the current ubiquity of "hacking"). Since the conference, the panelists revised their presentations into this collection of multimodal pieces, designed and edited by Jentery Sayers, with co-designing by Virginia Kuhn and co-editing by Mary Hocks. The eight pieces included here not only demonstrate how hacking is variously imagined and received across disciplines; they also give everyone involved a sense of possible next steps toward institutional critique and a feeling of camaraderie during the transition.

The immediate context for this current piece comes from Hacking the Academy, an edited, crowdsourced collection resulting from a call for contributions submitted within one week at the end of May 2010. Although an edited version appeared in 2013 from University of Michigan Press, the inspirational models continue to be available at the original Hacking the Academy site, which offers a flurry of manifestos and best practices for hacking academic institutional structures, scholarship, and teaching practices. Similarly, this collection is inspired by THATCamp, the rapidly growing cluster of unconferences for humanities and technologies in which conference agendas are created, developed, and enacted by participants more or less on the fly.

Hacking the academy through unconferences and unconventional scholarly communications fosters possibility and camaraderie while also subverting certain expectations of work and learning in the academy. In this collection, understandings of hacking emerged from earlier subversions, too. For example, Kuhn and Vitanza's "From Gallery to Webtext" (which offers a curated session of synchronous new media projects) subverted the traditional conference presentation and later appeared in a manifesto issue of the journal, Kairos: Rhetoric, Technology, and Pedagogy. Another manifesto—A Manifesto for Critical Media, by Eric Faden—called practitioners to teach media studies and production "by critically engaging film, video, and new media on their own ground and with new media's own tools, techniques, and technologies." Elsewhere, in 2004, Anne Wysocki simply re-defined new media in a theory-pedagogy context as attending to its own materiality and means of production. All of these inspirational statements and manifestos exemplify some of hacking’s core values: constructivist collaboration, collective learning, critique enacted through media, and an emphasis on the situated relevance of learning moments. Indeed, the crucial need for adaptable means that allow practitioners to move critically inside and out of academic structures created the kairos for this collection of classroom hacks.

Each contribution included here creates and enacts a type of hacking practice while highlighting or reflecting on its own materiality and construction. Hacking spaces—the physical, digital, and personal spaces of classrooms—and deconstructing normative assumptions about those spaces are constant themes across these eight pieces. The contributions also hack the act of writing—as code, as soundscape, as remix, as process log, as video, as image. The referenced assignments hack popular understandings of literacy by emphasizing multiple semiotic modes, production over products, context over content, and reflective awareness over expertise. Scholarly products and content expertise are often the primary expectations of academic literacies. In response, this collection of classroom hacks encourages forms of intensive learning conducive to tinkering, experimenting, iteration, and productive discomfort.

“Hacking the Classroom: Eight Perspectives" offers numerous ideas for reflexive teaching and pedagogical practice. These contributions also complicate the concept of hacking, and in particular Kuhn, Losh, and Yergeau offer provocative lists of norms and assumptions about hacking. However, the authors do not expect these eight perspectives to cohere, and the collection does not suggest that hacking classrooms should be understood uniformly across settings. On the contrary, the authors hope readers will note the discontinuities and overlaps across the eight pieces, prompting further dialogue about the culture, materials, and construction of classrooms in the near future.

Table of Contents

Jentery Sayers encoded this page in valid HTML5. All source files are available at GitHub.

Image below care of Cartegena et al.

Jim Brown

The Year of Computational Thinking

Video care of Jim Brown

Transcript for the Video

Something is in the air, and it seems that 2012 has been "the year of code." From Code Academy's “Code Year" project, to Cathy Davidson's call for algorithms as a "fourth R," to New York Times articles about programming "for the rest of us," there is a public conversation happening about how code is more than just a technical practice (“Codecademy" n.d.; Davidson 2012; Stross 2012). My own attempts to hack the classroom during this past academic year have happened with these broader public discussions in mind. I recently joined a brand new program in Digital Studies at the University of Wisconsin-Madison. This interdisciplinary program offers an undergraduate certificate in Digital Studies and currently includes faculty from four departments: Art, Communication Arts, English, and Journalism. Our focus is on providing students with a broad range of digital skills, from the visual to the aural to the computational.

Given this broader context ("the year of code") and my local context (UW-Madison's Digital Studies program), I have attempted to make this "the year of computational thinking" for students in my classes. And I guess you could say I have done this by hacking the classroom. For me, hacking is about exploring possibilities without worrying too much about what the end result will look like. I certainly hoped that students would leave the classroom with a better sense of that "4th R," but I also knew that I was experimenting with technologies and assignments that were brand new to me.

And so, my first hack has been the development of a studio pedagogy. Influenced by my colleague, Jon McKenzie, I have begun to see my classroom as a studio space. I have given students more time and space to make things. This has been helped along by my teaching schedule—the classes I taught this year met once per week, and this made it easy for me to compartmentalize time. For instance, we might spend 45 minutes discussing our reading before devoting the remainder of class to designing video games or interactive fiction. For me, this approach also emerged out of conversations with colleagues about teaching courses online. I tried to imagine what I would say if an administrator asked me why I needed classroom space. Why couldn't I just teach my courses online? We need good answers to this question. Online courses can be a good solution to certain problems, but they are not magic bullets. We need strong answers to questions about online teaching and the value of synchronous classes. This is one good reason to hack the classroom and explore its various affordances.

In addition to developing this studio pedagogy, I also built courses in which students wrote a significant amount of code. They used two different systems: Inform7 and Scratch. Both of these systems are designed for the novice programmer. Inform7 allows students to code using English language sentences, and Scratch offers a visual interface. I would like to briefly describe two of the more interesting student projects.

Bully Be Gone is a work of interactive fiction that intervenes in contemporary discussions about bullying. Rather than presenting statistics or anecdotes about bullying, this game places the player in a world and asks them to move through it. The game (spoiler alert) slowly reveals to the player that s/he is the bully. Actions that initially seemed like day-to-day activities (like taking an apple from a desk) are eventually revealed to be the actions of a bully, and the player must right each of these wrongs in order to finish the game.

Walker, Wisconsin Ranger is an attempt to address Ian Bogost's argument in Persuasive Games that political video games have largely failed to take advantage of the procedural affordances of games. Students were tasked with creating a game that addressed an issue in Wisconsin politics, and that game needed to make a procedural argument. Walker, Wisconsin Ranger, puts the player in the shoes of Governor Walker. Game play involves making budget cuts that inevitably affect approval ratings. The game makes a fairly complex procedural argument about politics and policy by immersing us in the world of Scott Walker. Walker, Wisconsin Ranger goes beyond demonizing Walker (a fairly easy task) in order to demonstrate the complexity of the decisions he faces.

In addition to these courses, I am looking forward to teaching "Composition and Computation" in the fall. This is part of a Freshman Interest Group I designed that will link together the concerns of composition studies and computation. I have immensely enjoyed this year of computational thinking. And while the Digital Studies program has allowed me to hack the classroom and push the boundaries of composition and rhetoric, I have been especially excited to watch my students hack in the classroom.

Image below care of Kaitlynn McQueston

Mary Hocks

Sonic Literacy: Resonance and Reflection

Video care of Mary Hocks

This contribution discusses sonic literacy and soundscape analysis assignments as the primary means for hacking a required senior seminar and the effects on both students and teachers when taken out of their comfort zones and tuned into the surround.

Transcript for the Video

[Music soundtrack begins (Hocks, "Spinning the Sky")]

So sonic literacy, first and foremost, is an embodied knowledge, and I define it as "the ability to identify, define, situate, construct, manipulate, and communicate our personal and cultural soundscapes." That is the highlight of this class. I am going to show you what a couple of students of mine have made of this in capstone projects that they are currently working on and the reflective writing that they are doing as a requirement for the class.

So you can see that she [Sarah Murphy] has, on her own blog (her own WordPress blog for the class), posted: [Soundscape of restaurant plays: background piano, voices, silverware and plates, and laughter].

So this of course is what we would call a soundscape. And sound locates us literally. What sound teaches us is that we are not separate from our environment. I have my students then analyze, using a series of what I call heuristics. It is a series of prompts and questions to describe their subjective experience with awareness and precision, and reflect on it. So you can see she says she loves Beauty and the Beast. She is describing some of her embodied experience of hearing this sound at a dimly lit Italian restaurant. And then her companion Joseph is reporting to her; he was expecting a bunch of cheesy ballads, and he was worried that the performer was going to ask him to put in a request. So they are having very different personal experiences to the soundscape as well. And so her reflection continues in this way (Murphy, personal communication).

Resonance is the word that my collaborator, Michelle Comstock, and I have chosen to describe when a sonic literacy works for an audience. So we want to begin to define how sonic projects create and engage audiences. We call that "resonance." Resonance is a metaphor, of course, that we use all the time: "I resonate with that idea." But we are also looking at a literal embodied resonance. And so there is an attunement, a sympathetic set of connections between audience and author. It is very rhetorical. That is what we are after when we talk about a rhetorically savvy and defined production.

Paying attention, focusing attention, and creating a mindful presence are some of the things that sound requires of us that are a little different from visual and other digital literacies. And so there is actually a current movement of integrating mindfulness training into education and learning from elementary schools to medical schools. Mindfulness is a valuable skill that comes out of a rich history and tradition and strong ethic.

[Music begins.]

Resonance, reflection: Those are the hallmarks and highlights of my class, my teaching, and also my research about this type of pedagogy. I think we get attention to discomfort in the sonic environment, and that wakes us up to the soundscape in disruptive or disturbing ways that resonance may not. [Music swells, overpowers voice.] Dissonance also occurs when students are grappling with new technologies, and new software, and new iPads. And teachers like ourselves are also grappling [music lowers] with dissonance [laughs] and some productive tensions and frictions when we use new technologies. This is something that I am very interested in as a teacher, a trainer of teachers, and somebody who focuses on pedagogy as a field of scholarship, a practice, and a reflection.

So I hope that the little bit that I have shown you today has intrigued you and shown you enough to want to hear more.

[Music fades out.]

Image below care of Aimée Knight

Aimée Knight

We Need to Talk

Space impacts learning. Designed spaces can encourage exploration, collaboration, and engagement. Or physical spaces can say it's alright to check-out and go to sleep. When I came to Saint Joseph's University, I began designing and building learning spaces that are first and foremost social spaces. Today, in an era of distance learning and MOOCs, where education is moving online, people's physical presence is valuable indeed. Everyone in the room is physically present to engage in the exchange of ideas and build knowledge together. That may sound obvious for an institution of higher learning. Yet, as we look around our universities, we see that most of our classrooms are not designed to increase human contact and communication. And this goes for our technology classrooms as well, where students have obstructed views and can easily hide behind stationary monitors, engaging with no one for the entire period. As I discussed at Computers and Writing in 2012, a technology classroom that values and encourages active participation is still the exception to the rule.

Poster on Classroom Design
Image care of Aimée Knight. Download it in Portable Document Format.

My department takes a production-oriented approach to digital media studies and involves students in a variety of hands-on projects to develop multiple literacies, including blogging, web development and design, digital aesthetics, writing for publication, digital storytelling, audio and video editing and production, and presentation delivery and design. Our curriculum, centered on digital production, emphasizes hands-on, experiential learning. All students in our Communication Studies department combine theory and practice as they “learn by doing.” Projects focus on the creation of media-convergent texts that combine multiple modalities, including sound, image, and user interaction.

In order to teach this curriculum, we needed to hack some classrooms. We needed spaces that encouraged active, experiential learning. It used to be that, “To prove your academic seriousness, students should be almost dead, quiet, asleep, not up, excited, buzzing, lingering around the classroom” (hooks 1994). It is my goal to design spaces that enact that pedagogy—the “excited, buzzing, lingering” kind. As knowledge is socially constructed, always done together, I set out to design teaching and learning spaces that increase human contact, communication, and collaboration. To achieve this goal, I believe the focus of classroom design needs to be on people, not technology. When the focus is placed on active, social, experiential learning, technologies move into the background.

When students are asked to imagine an ideal learning space, “Students want display screens, so work can easily be shown and shared among small groups. Students want laptop-friendly, wireless spaces, where they can easily move around. Students want food, drink, and natural light” (Walls, Schopierary and DeVoss 2009).

In a collaborative learning space, everyone participates. Everyone works. There is no crowding around a single screen. There is no looking-on as someone else types and edits. There are no obstructed lines of sight. Students decide where, when, and how to use the technology, if at all. The technology does not dictate outcomes; it facilitates them.

This video features faculty and students who teach and learn in Merion 150, in the Communications Studies Department at Saint Joseph’s University. This was the first of our collaborative learning spaces. The flexible studio environment encourages active participation and features eight wall-mounted HDTVs with notebook and tablet computers for student use.

Video care of Aimée Knight. Transcript below.

Merion 174, pictured below was the second classroom redesign, completed in Fall 2013. The room features wall-mounted HDTVs, breakaway tables and chairs, sound domes, XBox video game consoles, Tidebreak’s collaborative learning software, and a technology cart with notebook and tablet computers for student use.

Image of a Classroom at St. Joseph's University
Image care of Aimée Knight

The custom-made Brown Innovations Sound Domes installed in the classroom have directional speakers that localize sound. They focus the sound for small groups directly under the speaker dome, which keeps the overall classroom noise to a manageable level.

Students Using the Classroom at St. Joseph's University
Image care of Aimée Knight

The classroom features Tidebreak’s collaborative software, ClassSpot. Students are able to share screens and files with each other. They can remotely take control of any screen in the room—including the screens at the front of the room—which speaks to the student-centered pedagogy we value in our department.

Students Using the Classroom at St. Joseph's University
Image care of Aimée Knight

With movable white boards, couches, and comfortable chairs, the room can easily be re-arranged to suit a variety of needs, including small group work, usability testing, and gaming. Everything in these classrooms is flexible and mobile. An active learning classroom must grant students freedom to configure (and reconfigure) their environment.

Transcript for the Video

Text in video: We Need To Talk. Students and faculty on classroom design. Unscripted.

Katherine Sipio, student: “The classroom doesn’t have the feeling like you’re being lectured, like you’re not at a desk, like, looking straight ahead. You are interacting with the students that are next to you or the professor. So, I think that’s why it has a different feeling to it.”

Mike Lyons, Assistant Professor: “The center of the classroom is a space where we talk. And the technology is not front and center in the room. The technology is probably where it should be—and that’s on the periphery. There’s almost this kind of migration, you know, of talking to doing. It’s this very natural migration from the center out to edges."

Lauren Fiatoa, student: “Having the larger screens help the entire group stay on point and together, rather than having us on individual computers. It’s about helping each other and learning from each other.”

Katherine Sipio, student: “I like the layout of the classroom because it’s easier to talk to people.”

Mike Lyons, Assistant Professor: “It’s the idea that students aren’t passively consuming. They’re active, and they’re creating their own learning environment. To do that you need a classroom that’s movable and changeable to meet their needs. It’s a people-centered, idea-centered classroom.”

Lauren Fiatoa, student: “We have the space to learn and then make mistakes and learn again.”

Mike Lyons, Assistant Professor: “The classroom adapts to what we’re doing. Rather than having us adapt to the space, the space is designed to adapt to what we do—and I think that’s really important.”

Text in video: Thanks to Communication Studies students and faculty at Saint Joseph’s University.

Image below care of Jeremy Eichenbaum, for the U. of Southern California (USC)

Virginia Kuhn

Hacking My Head

In this exploration of hacking, I move away from a critique of institutional structures—those constraints that arise from outmoded disciplinary boundaries, curricular edicts, and theoretical biases. It is not that I don’t have a lot to say about these limitations—I do, and I have—but at the level of the classroom, I am also lucky to have a lot of freedom. I designed most of the courses that I teach, and I update curricular materials regularly given the emergent nature of the work I do. Housed in the University of Southern California's School of Cinematic Arts, all of the courses I teach marry theory and practice, and I direct an undergraduate multimedia honors program as well as a graduate certificate, Digital Media and Culture.

Further, there is typically far more freedom in graduate classes, so the need for hacking may seem less immediately apparent. But the theory-practice model is hard. It is hard at the undergraduate level, where conceptual rigor must be maintained even as the technologies keep shifting; but it is devilishly hard at the graduate level, where written language is still seen as the pinnacle of sophisticated academic argument. Moreover, with the exception of the work of a few key scholars in Rhetoric and Composition, and this publication in particular, there is a dearth of scholarship on graduate pedagogy. Therefore, I felt the need to turn the critical lens on myself, reflected upon my graduate pedagogy, and concluded that I need to hack my own head. I found that I needed to reconsider my preconceived notions and the ways in which I may have been clinging to an old paradigm about graduate education.

Virginia Kuhn and graduate student, Alex Agloro
Virginia Kuhn and graduate student, Alex Agloro. Photo by Jeremy Eichenbaum for USC.

Here, then, I offer three mandates to illustrate the ways I have hacked my own head in the service of hacking the classroom. Initially, I was surprised to see that I phrased these in the negative—a list of don'ts rather than a list of dos—but on second thought, the very impetus for hacking is one of remedy: it is a response to a problem, or the recognition of a flaw that can be improved. As such, the nature of my list makes perfect sense. These mandates reflect the flaws I detected and attempt to remedy in an ongoing way.

Don't assume students can recognize your biases.

Any graduate seminar I teach includes students that represent, potentially, four or five disciplines. It is not enough to assume students know my theoretical orientation; I must also be sure to affiliate myself given that, ultimately, the responsibility for the class lies with me. I do not like the lecture format, but have lately spent far more time in presentation mode, especially early in the term, in order to explain my approach and contextualize the reading, viewing, and production work. I have always encouraged students to question authority; I now foreground course assumptions immediately, but I am also more explicit about inviting students to challenge these assumptions.

Further, while I used to shrink from assigning my own scholarship, I now see that it is often the best way to reveal my stance on contemporary issues around privacy, copyright, digital labor, intellectual property, and the like—topics that are, in many ways, quite controversial. It always felt vaguely vexing or even somewhat unsavory for faculty to assign their own work in class, and I am not exactly sure why. Perhaps it was a sense that doing so somehow exploits a captive audience, or maybe it was the hint of financial gain. But upon reflection, such concerns aren’t really valid, especially given that the course is not mandatory and I assign open access publications.

Don’t privilege one semiotic register (e.g., text) over others (e.g., image, sound, interactivity).

Although I have long since balanced my approach to various semiotic registers in assigning undergraduate student work and in my own scholarship, when it came to graduate studies, I reverted to a far more conventional approach: assign 90 pages of reading per week and expect academic prose in response. My academic home, the Institute for Multimedia Literacy (now the Media Arts + Practice Division), only began offering graduate courses in 2010, and for the first several semesters I was the only faculty to teach them. Even as I tried to mime the undergraduate sequence, which can be somewhat reductively framed as the following trajectory—word > image > moving image > interactivity—I lowered the production load from the undergraduate version, assuming the conceptual part to be most important (and after students struggled greatly with it in the first iteration).

And yet, I wholeheartedly believe in practice-based research, that one must think through the media not just about it. So I now build in revision practices, whether through requiring a rough cut and then a fine cut of remix videos, or by marking up image assignments like the one pictured below, which assumes a revision even if it’s not technically required. I also intend to raise the production level again, since these students will often be faculty themselves, and certainly need this type of practice with digital media. That said, this particular mandate is amended by the corollary edict: don’t forget writing, since I’ve found students to be less careful in writing when the wiki into which we place all of our course work is set to a theme that looks less like the white page into which most academic writing is placed. I often switch the wiki theme midstream, in order to defamiliarize the writing that takes place there.

Revision Sequence Panel: a) student project, b) faculty feedback, and c) revised project
Revision sequence panel: a) student project (Jessica Koslow); b) faculty feedback (Virginia Kuhn, TA Susana Ruiz); c) revised project

Don’t assume critical consciousness when it comes to media production.

Graduate students, especially those in the humanities, tend to be educated toward complex verbal language, both written and spoken, and away from image production. And, as one colleague quipped, once there is a soundtrack involved, the work is no longer considered scholarly by any stretch. As such, it is easy to forget to actively foster the same sort of critical engagement with the language of images, sound, and interactivity. When students are learning a new technology—video editing, for instance—their focus on the conceptual issues often wanes. However, given the highly visual nature of multimodal work, the ethics of representation becomes a vital area of inquiry and one for which I initially failed to spend adequate class time.

Assuming graduate students have a level of critical consciousness is a fairly safe bet given the demographics of the students I teach—they hail from departments such as Critical Studies and American Studies and Ethnicity—but the ability to transfer that sensibility to media production is not so straightforward. By way of remedy, I have returned to screening Marlon Riggs’s Ethnic Notions in addition to John Berger’s Ways of Seeing, the BBC television series that later gave rise to a book of the same title. Moreover, I return to screening the films of Trin T. Minh-ha, such as Surname Viet, Given Name Nam, which complicates the form itself, and particularly the genre of documentary. Indeed, troubling the binary between fact and fiction is important since all such work is mediated.

Image titled 'Ethics of Representation'
"Ethics of Representation," illustration by Virginia Kuhn

I may never find the perfect balance of lecture, discussion, workshopping, reading, viewing, and production in my graduate seminars, but I will always try to find opportunities for graduate students to work toward a project that is somehow useful to them, whether for dissertation research, a conference submission, or a publication. I am also committed to remaining open to their feedback and input without surrendering my responsibility for running the class. In this way I hope my head hacking remains perpetual.

Image below care of Viola Lasmana

Viola Lasmana

Remixing Spaces and Texts

Assemblies. I associate this word with fond memories of going to primary and secondary school in Singapore, lining up in a single file every day for morning assemblies, where the whole school would recite the national anthem and pledge. These reminiscences are not merely moments of nostalgia, but they also allow for a critical reflection on what it means to engage in such structured ways of organizing ourselves. In this piece, “Remixing Spaces and Texts,” I turn to modes of scholarly practices that allow for disassembling and reassembling, and argue that knowledge production cannot simply follow the model of ordered assembly. If we think of scholarship as assemblages, and take on the role of designers who assemble and reassemble different components to create a new, remixed yet cohesive work, we can, as Anne Balsamo suggests in Designing Culture, “hack the present to create the conditions of the future” (Balsamo 2011). Here, I explore multimodal composition as a transformative scholarly practice, and offer examples from various projects that incorporate and also go beyond traditional scholarship.

Video Remix

As a generative mode of intellectual and affective scholarly practice, video remix allows the author to mobilize language and texts in innovative and radical ways. In “The Rhetoric of Remix,” Virginia Kuhn argues that we can “change semiotic privilege by shaping the emerging discursive field to one that more readily reflects an equitable pluralistic culture” (Kuhn 2012). Indeed, remix is about new ways of seeing, about mobilizing sites of possibility and alternative meaning-making. In an early work I produced for a seminar on contemporary digital media at the University of Southern California’s Institute for Multimedia Literacy (where I explored video remix for the very first time), I enacted the theoretical work I was doing in thinking about the intersections of memory and technology. Video remix allowed me to engage both theory and practice, and pushed me to reimagine what composition and recomposition mean.

Video care of Viola Lasmana

Redesign Project

In these redesign projects, I reworked images in the style of Shepard Fairey and Barbara Kruger, and placed specific words in strategic parts of an image, as well as utilized purposeful colors and shapes in redesigning a text. In Krugerizing a 1903 image of the first successfully flown powered airplane, I wanted to allude to the implications that flight as an industry had for the Futurist movement (1909-1916) and World War I (1914-1918). In remaking the cover of Toni Morrison’s novel, Beloved, the Fairey-esque rays are my interpretation of the explosion of the invisible into the visible (history making itself felt in the present, and Beloved returning as a ghost in the liminal space of visibility and invisibility).

Image Titled The Skiy is a Field
Image care of Viola Lasmana

Image Exhibiting the Remake of the cover of Toni Morrison's novel, Beloved
Image care of Viola Lasmana

Rethinking the Book

Scalar is a media-rich authoring platform, developed by the Alliance for Networking Visual Culture (ANVC), that allows authors to assemble and reassemble media in innovative ways. It affords a space in which to rethink the ways we read, write, and create scholarship. In my Scalar book, “Singing the Body Electric: Technologies of Communication and Whitman as Proto-Futurist,” I was able to have text, video, and images interact smoothly with one another without having one supersede the other in terms of importance: all of the different modes of expression are valued equally, and this allowed me to immerse myself in an act of composition that was radically different than traditional ways of writing.

Screen Shot of a Scalar Book made by Viola Lasmana
Image care of Viola Lasmana

As suggested in these multimodal texts, the opening up of spaces—where a variety of representational modes can thrive—allows for a kind of scholarship that, as Edward Said describes in “Professionals and Amateurs,” is inspired by “love for and unquenchable interest in the larger picture, in making connections across lines and barriers” (Said 1994). These are projects that make creative, cultural, and political statements by experimenting with different aesthetics and forms of media, as well as by merging form and content, and theory and practice.

Image of the Institute for Multimedia Literary at the University of Southern California
Image care of Viola Lasmana

Image below care of Nina Belojevic

Elizabeth Losh

Ten Principles for a Hacktivist Pedagogy

Slide deck care of Elizabeth Losh. Images in the deck care of Ioana Patringenaru, Adriene Jenik, Elizabeth Losh, and Jeremy Douglass.

A hacktivist pedagogy combines an engagement with social justice with an enthusiasm for subversive tinkering with the specific aspects of blackboxed machines. Much as feminist pedagogy suggests a possibility to reposition power relations in the classroom toward more egalitarian, collaborative, process-based, experiential, interactive, connected, and relational practices, a hacktivist pedagogy challenges disciplining models of education.

Recognize that affect matters.

Often the image of the powerful feelings stirred up by a frustrated user experience approaches the ridiculousness of the famed “Angry German Kid.” But affect is a critical part of education. Rosalind Picard, who is often called the founder of affective computing, notes that computers lack the sensibility of “the good teacher” who “detects important affective cues from the student and responds differently because of them” in explaining robotic intelligence and cases of mutual incomprehension between people and machines (Picard 1997). As Megan Boler asserts in Feeling Power, disciplining emotions is part of how social control is maintained in the classroom (Boller 1999). And yet many students who struggle with new technologies in meaningful ways often feel sad, angry, or exuberant in ways that challenge classroom norms. Giving permission for students to cry when data is lost or software crashes inexplicably with an unsaved project can be an important part of effective teaching with digital technology.

Be skeptical about gadgets.

The advent of cheaper gadgets, such as Raspberry Pi, to teach programming is certainly exciting. A computer smaller than a pack of cards where the chip and circuits are laid bare seems a liberating device in that it avoids the appearance of the consumer electronics industry and the slick blackboxed technologies that it mass-markets. Yet Raspberry Pi is also a gadget, and like all devices intended to make the evangelical mission of disseminating technoculture easier, there is a complicated history of One-Laptop-Per-Child thinking. Consider how mass distribution efforts of iPods on the Duke campus should make administrators skeptical about similar mass distribution efforts involving iPads.

Allow for rhetorical occasions.

Wayne Yang has argued that classroom experiences have distinct seasons, which may include a “season of reading,” a “season of writing,” and a “season of performance” (Yang 2009). Although digital reading is often seen as an intensely private act, even single-authored digital pieces can be “driven” by others in a smart classroom setting, and navigating as a reader can create a kind of participatory public performance in which audience members may suggest directions, which the person—who is the center of attention in an “open mouse” setting—might “steer.” Final performances can be an important part of the digital classroom, and it is certainly a way to bring responsibility, accountability, and improvisation into such classrooms in ways very different from the distance learning that administrators might imagine in thinking about “instructional technology” in the narrowest of ways.

Teach code.

Code literacy can be incredibly powerful for students, particularly those who are most likely to feel disenfranchised by brogrammer culture. Elegant and user-friendly languages like Processing with large libraries built by DIY communities might be ideal for this purpose.

Don’t teach code.

Workarounds are an important part of computational thinking, and sometimes the best work done in a digital classroom might by the students who aren’t turning in projects that display a virtuoso mastery of programming. Interesting hypertexts can be created with PowerPoint, YouTube, Facebook, and even pieces of paper. Besides, being too doctrinaire about anything might betray inflexible pedagogical thinking.

Don’t get married to any one platform.

Learning how to learn is a critical part of computational culture, and planned obsolescence seems to be a defining characteristic in the digital humanities. For those of us who have created elaborate lesson plans to teach our students Flash for many years in a row, we need to be prepared to move on.

Get married to a platform.

Making the commitment to work with the developers who grapple with Scalar, Neatline, or other tools to enhance the possibilities of the digital page is an opportunity not to be missed.

Let students steer the boat.

Students need to create projects that are meaningful to them, whether it is promoting a cupcake company or creating an online wedding website for out-of-town guests. Don’t dismiss ideas that seem banal in their practicality, since there are always ways to bring design, critical thinking, and consideration of community values into play.

Require students to unmix as well as remix.

There are too many remix assignments that are not challenging to students that produce work that lacks rigorous work with research questions or iterative practices. Why not ask students to unmix footage from remix video to identify all of the sources from which it was composed? The complexities of media visualization software might be too much for your students. But simple tricks, like using Shazam to identify music tracks or Google image search (with a screen grab) to find images, can be remarkably effective.

Find multiple posses.

Networked classrooms require us all to share and communicate, and we need to move between disciplines and out of the comfort zone of composition whenever possible.

Jentery Sayers

git commit -m "The Classroom"

During the last two years, I have grown increasingly keen on "gitting" the humanities classroom. Git is a version control and source code management system popular among software developers. It allows a group of people to build a single repository of files across numerous machines in a non-linear fashion, while generating a detailed change history of that repository. Individual contributions require neither network access nor a central server. Importantly, all "commits" (i.e., recorded changes) to a repository are saved as components of its change history, even if they are not merged into its main "branch" (i.e., line of file development). In other words, with a Git repository comes many witnesses: a project's current state is always accompanied by the files it was and the files it could have been, with attribution for who committed what when.

Graph of Commits Made to a Git Repository
Visualization of commits to a Git repository. Image care of the Maker Lab in the Humanities.

Technical details aside, gitting the humanities classroom is a form of hacking the classroom because version control and source code management are not practices common to humanities teaching, learning, research, and writing. They are most often associated with the software industry, computer science, or information studies. Put differently, Git was not really designed for most humanities work (e.g., writing essays and monographs), even if many humanities practitioners and projects—for instance, The Programming Historian, Debates in the Digital Humanities, and Scalar—use both it and GitHub, a web-based hosting service for sharing Git repositories.

Screen grab of the Git Repository for the book, Debates in the Digital Humanities
Screen grab of the Git repository for Debates in the Digital Humanities. Image care of Cast Iron Coding, Inc.

Git best lends itself to building, documenting, versioning, circulating, and debugging programming projects, and thus the people who use it extensively tend to know at least one programming language. They also tend to work from the command line, instead of relying on a graphical user interface (GUI) for human-computer interaction.

But gitting the humanities classroom need not—and arguably should not—be reduced to simply recontextualizing Git, porting it from industry and the sciences into the humanities classroom. In and of itself, such recontextualization does not necessarily make a technology relevant to humanities practitioners, let alone conducive to a particular humanities pedagogy or research program. Unless an instructor's goal is to prompt students to experiment in a sandbox of tools, or to simply integrate a delivery mechanism (e.g., Moodle or Blackboard) into the architecture of a course, then teaching and learning a technology typically demands a clear and communicable reason—or at least a working suspicion—why a certain application is being used to facilitate the express learning expectations of a course. In short, Git in the humanities classroom, but for whom, under what assumptions, and to what effects on teaching and learning?

Screen Grab of the Course Site for English 507, a Graduate Seminar at the University of Victoria
Screen grab of English 507 at the University of Victoria. The web page features the course's learning expectations.

With these points in mind, none of the following possibilities is the primary reason I git the humanities classroom at the University of Victoria (UVic):

  • Code is the new literacy.
  • "Real" developers write from the command line.
  • Git's hip.
  • It's popular within and beyond the academy.
  • It's empowering.
  • I want to sell students and other instructors on it.
  • I use it and think other people should use it, too.
  • Because change.

Taken together, these eight reasons fall under two more general, seemingly ubiquitous claims:

  • "You should learn Git." (Example 1, 2, and 3)
  • "Everyone should learn how to program." (Example 1, 2, and 3)

But—like writing—coding isn't just coding, and gitting isn't just gitting. There are many ways to version and program, across a variety of languages and settings. Indeed, context matters. For example, two popular programming languages, Python and Processing, are quite different, including differences in paradigm, syntax, and use culture (e.g., Processing was developed to render programming friendly to artists and designers). These differences extend to the applications of Git, where developers may have distinct protocols for documenting change, stabilizing repositories, and releasing code. Moreover, both programming and versioning are frequently embedded in deadline-driven projects, with particular mandates and working conditions that affect how this becomes that over time. The same applies to the classroom, where coding and gitting are entangled in disciplinary expectations, assessment strategies, and teaching and learning dynamics, meaning gitting in the classroom will not always translate neatly into gitting elsewhere, including work in private and public sectors.

Likewise, the "you" or "everyone" in any call to learning needs to be unpacked. In the case of classroom learning, instructors benefit from thinking through the assumptions of exhorting students to code, including why people's backgrounds, interests, identities, biases, and trajectories matter (Jackson et al. 2008). As Miriam Posner argues in "Some Things to Think about before You Exhort Everyone to Code," "men—middle-class white men, to be specific—are far more likely to have been given access to a computer and encouraged to use it at a young age." She continues: "'the culture of code,' the inside jokes and joshing that you enjoy, may not be equally appealing to everyone who encounters it" (Posner 2012).

If, following Posner, Git and Git culture are not value-neutral, then neither is gitting the humanities classroom. Recognizing how technological development is intertwined with differences across race, gender, sexuality, ability, class, and language, it should account for what students have not learned or accessed, how cultural assumptions congeal around technologies, and how access to technologies is not synonymous with knowledge production or systemic change.

In my case, teaching technologies in the humanities classroom involves me acknowledging when and how I am part of the problem: how, as a middle-class white man, I at once represent, enable, and benefit from privilege, a privilege that's only compounded when gadgets, code, and computation are at play.

Beyond that acknowledgment, it also involves me actively avoiding assumptions that, for example:

  • I know what's best for students, especially students who have not had access to computing or programming.
  • Classrooms are somehow outside the social and material conditions in which they are embedded.
  • "Playing" or "screwing around" with technologies is always innocent or inconsequential.
  • The burden to remedy widespread technological disparities falls on the disenfranchised, who should simply "catch up," get educated, be creative, act as tokens for the problem, or tell people in privileged positions what the fix is.
  • Social justice issues can be addressed through technologies alone.

Avoiding this last assumption implies teaching technologies with a healthy dose of skepticism—say, skepticism about recent exhortations to learn to git and program.

Inspired by the work of Posner, as well as Cheryl Ball, micha cárdenas, Wendy Chun, Matthew Fuller, Radhika Gajjala, merritt kopas, Lauren Klein, Erik Loyer, Tara McPherson, Bethany Nowviskie, Paolo Pedercini, Amanda Phillips, Andrew Ross, and Cynthia Selfe (among many others), my classroom hack encourages applied critiques of technological development—critiques that blend computing with cultural studies, knowing with doing, reading with programming, and immersion with distance, so that all involved can collectively develop a granular sense of how technologies at once reflect and shape social relations, often beyond our perception.

To be sure, this hack cannot put all of its weight on a system like Git. As the course site for English 507: "Arguing with Computers" at UVic suggests, the classroom routine also includes group discussions about current media studies (e.g., Lisa Nakamura's recent publications on race, labor, and gaming); hands-on workshops on programming and the command line; conversations about how we variously value, benefit from, and resist computing; and presentations of prototypes and writing in progress. Ultimately, the goal is for us to engage technologies across numerous perspectives and scales, but without ignoring the relevance of learning and, wherever possible, changing computing practices. My hope is that working with and through technologies such as Git—in order to understand how they function and influence social relations—complicates claims premised on privilege, positivism, and self-absolution. Sure, students will not leave one of my humanities courses with certification in a programming language; however, they do have opportunities to develop multimodal strategies for cultural computing: strategies that persist beyond the changing particulars of platforms and the always shifting conventions of code.

Which isn't to say the technical particulars are irrelevant. For instance, gitting the humanities classroom requires some rather intricate planning to integrate versioning, programming, and the command line into the humanities classroom. It also demands accounting for hiccups, frustrations, and differences across platforms.

Accordingly, for the balance of this piece I briefly walk readers through a snapshot of not only how I use Git in my courses but also what gitting looks like for students and me. To give gitting a sense of detail, I provide some screen grabs of my own use of the command line, together with commentary following each Git command. In the screen grabs, the commands follow jenterysayers$, and the comments follow the # mark. I also contextualize each command and conclude with some social and cultural implications of gitting the humanities classroom. Of note, if you are unfamiliar with Git or GitHub, then I recommend Konrad M. Lawson's "Resources for Learning Git and GitHub," written for ProfHacker. There, Lawson provides a wonderfully thorough and informative list of resources, which represent a variety of humanities and computing perspectives.

Screen shot of the command line: Create a single repository of materials for an entire class

Create a single repository of materials for an entire class. I usually start a course by creating a repository of files to which everyone will contribute. In the example above, I use the mkdir command to create a directory, named hackingTheClassroom, on my local machine. This directory becomes the shared class repository. As I mentioned earlier, the development of any Git repository can occur without network access or a central server. It's distributed. For example, students can work on a file without being in the cloud.

Screen shot of the command line:: Record all changes to that respository

Record all changes to that repository. Now I'm using the init command to initialize my hackingTheClassroom repository as a Git repository. This means that all changes to the repository and its files (including additions and deletions) will be tracked, in a fashion loosely similar to "Track Changes" in Microsoft Word, but at the level of an entire directory.

Screen shot of the command line: Everyone routinely contributes to the shared repository

Everyone routinely contributes to the shared repository. Now it's time to start creating files (e.g., readMe.txt) and adding them to the class repository, using the touch command. Since touch simply creates an empty file, I can use the open command to open readMe.txt, edit it, and save it. Usually, in a file like readMe.txt, I include important details about the course. And then I walk students through creating, editing, and saving their own files, with each student regularly contributing to a single "log" file (usually named something like studentLastName.html) in the repository throughout the semester. This approach is comparable to students contributing to a blog; however, here they are by necessity sharing their source files with the entire class. While regularly writing to these log files, they might also add research materials (e.g., screen grabs, PDFs, and spreadsheets) to the class repository. This way, everyone in the course, including me, can see and access what resources the class is compiling over time. Over the course of an entire semester, writing and research processes gather collective steam and are exhibited through material changes routinely contributed to a shared repository. If students are producing graphs for their essays, then they can include their XML data in the repository. If they are closely examining a set of public domain images, then they can include them in a folder of JPGs, PNGS, or the like. If they are drafting a literature review, then they can include an annotated bibliography with encoded references to the annotated texts. And so on.

Screen shot of the command line: A working tree or index of changes develops over time

A working "tree" or index of changes develops over time. Again, one benefit of Git is that all repositories have a change history, expressed through a "tree" or index. In the instance above, I am using the add command to "stage" changes I've made to the repository. These changes include edits I made to the readMe.txt file. The next step is "committing"—or recording and describing—those changes.

Screen shot of the command line: Commits become significant paratexts

Commits become significant paratexts. By recording, describing, and attributing the changes made to a repository, students and I draw attention to its iterative development, not to mention the fact that such documentation might be informative for other contributors who may examine, use, and change the files contained therein. Put differently, the repository cannot be reduced to a primary text, or merely to the content of its files. Even in the aggregate, material such as metadata matters, too.

Screen shot of the command line: the repository is circulated online

The repository is circulated online, either privately or publicly. Using GitHub, the class repository can be shared not only with class members but also—if the students so collectively choose—with people who are not registered for the course. In other words, repositories can be declared discoverable or hidden ("public" or "private," respectively), and they can be: 1) downloaded, where the files, but not their complete change history, are compressed and saved to your local machine; 2) "forked," where the files and their complete change history are copied to your GitHub account, on the server side of the hosting service; or 3) "cloned," where the files and their complete change history are saved to your local machine. With students, I usually decide whether the repository should be discoverable and when. In the meantime, they can use the command line to routinely "push" (git push), "fetch" (git fetch), and "pull" (git pull) changes.

The social and cultural implications gradually become apparent. With this admittedly brief snapshot in mind, here are a few social and cultural dimensions of gitting the humanities classroom:

  • The Blur: When using Git to compose a shared repository, neat demarcations between academic writing and coding are blurred. For instance, the logic of "commits" can be understood through the legacy practice of revising research essays as well as the longstanding relevance of paratexts to humanities scholars. One implication of this blur is troubling assumptions that any particular discipline is a best fit for programming. Another implication is rendering code more approachable to people who are new to the command line, and then underscoring how both writing and code are translated from one setting to the next.
  • Demystifying the Command Line and Code: Popular representations of programming—in films such as Hackers—tend to glamorize code and the command line. But, truth be told, coding is quite banal, and it is commonly deemed a "service" activity at universities and elsewhere. By extension, if claims that everyone should learn how to program do render coding a thrill, then repeatedly typing git push throughout the semester may very well diminish that thrill. Similarly, the repetition necessitated by Git demystifies, or at least toys with, the often intimidating culture of the command line. Once people are able to execute a few commands, especially from memory, then they can peel back the sheen surrounding the practical realities of programming and articulate how and when representations of coding are embellished or over-rated.
  • The Command Line Isn't Sacred: Working with Git for an entire semester complicates claims that the command line is where "real" programming happens: that it is some sacred space superior to the WYSIWYG world of "lay users." In the last instance, some people may find the command line appealing, while others may prefer GUI-based interfaces. Whatever the case, building a shared repository helps everyone involved realize that—like all interfaces—the command line is simply one more form of mediation. It is neither somehow immediate nor necessarily "closer to the source" than graphics or icons. Plus, visual approaches to programming (e.g., Scratch, Twine, and MaxMSP) are frequently more appropriate for certain projects, particularly when learning or using the command line becomes time-consuming and cumbersome. Put this way, gitting the humanities classroom frames the command line as yet another filter through which thinking, compiling, and expression occur.
  • Speaking Git: To engage Git is to unpack the terminology that congeals around it. As with other applications, learning Git is largely about learning and performing a language. To borrow from Cox and McLean (2012), writing and executing code cannot be separated from speaking in code. By highlighting its constructedness, approaching Git as both a language and language community may prove less intimidating to humanities practitioners. It is also an opportunity for language games, quirk, and humor in the classroom: "I git you," "I'm committed to this project," and so on.
  • Git, by Whom?: As people learn Git, they will likely turn to question-and-answer spaces such as Stack Overflow for more information. These spaces are not merely guides or manuals. They are where Git and other technocultures happen online, and they can be examined as such. For example, recent research (Vasilescu et al. 2012) suggests that Stack Overflow builds barriers to participation by women—barriers which correspond with sexism in programming communities or "brogrammer" cultures. With this research in mind, the routine use of Git can be anchored in conversations about who participates in, represents, and benefits from its development, as well as why persistent self-reflexivity about computing culture is necessary when engaging disparities.
  • Frustrated? It Might Be Political: Git inevitably frustrates people, and for good reason. While working in the command line, talking openly about this frustration can be quite productive. What is insinuated by statements such as, "It must be a user problem"? How does code or the command line foster impostor syndrome? As a form of mediation, what does the command line fail to communicate (especially to people who are accustomed to GUIs or other modes of interaction)? When and why is programming not simply a matter of "common sense" or universal logic? Articulating responses to such questions is not a distraction from the programming tasks at hand; doing so directly addresses the oft-ignored, embodied labor of those tasks.
  • Dating Our Machines: Neither code nor the command line is somehow independent from the platforms on which it runs. As such, "dating" the machines we use—noting exactly which operating systems, versions, and settings are helping us execute this into that—draws attention to the temporality and materiality of computing. For instance, the time required to push and pull changes to a shared repository will differ across machines and settings. Also, commands may not be consistent across operating systems. So, instead of proceeding as if software functions immaterially and identically for everyone—or as if processing, speed, and memory are uniform across contexts—dating machines stresses important distinctions steeped in circuitry, hardware, and legacy systems. It also raises questions about access. What is defined as a new or obsolete technology is highly dependent upon context and material conditions. And how Git projects persist depends in part on how interoperable or flexible they are.
  • A Launchpad: For some, Git is a sandbox of sorts—a launchpad into experimenting with programming and versioning. Humanities practitioners who become interested in it may be prompted to learn, say, Python, Processing, HTML5, or R. Or they may want to apply the logic of software versioning to other scenarios, including the study of literature or the publication of monographs. This sparking of new interests can encourage us to expand the workflows through which humanities scholarship is produced, stored, revised, communicated, and shared, adding layers of meaning to "writing" in academic contexts.
  • The Metadata Industry: If, with Git, commits are significant paratexts, then its use in the humanities classroom invites us to examine how metadata (e.g., the descriptions of a change to a Git repository) are becoming increasingly relevant to computing culture. Here, consider how social networks rely heavily on the information affixed to communications: likes, favorites, retweets, timestamps, attributions, geolocations, and so on. For many industry practitioners, this information, or metadata, is valuable. It feeds back into advertising, user scenarios, interaction design, and infographics. Understanding, through Git, how such metadata is generated can increase awareness of how it is abused, how digital labor is productive of value, and how (where necessary) to build networks or communities motivated by alternative means of exchange.
  • Committing for Future Audiences: Finally, Git's emphasis on building a change history implies constructing a repository for audiences yet to be determined. A somewhat speculative practice, this aspect of Git asks practitioners to consider how their work will be read, used, and even revised. What information will be helpful for future forks? How might paratexts highlight important shifts or decisions in a project? What has not yet been done that could be done by others down the line? That is, what gaps currently exist in the repository? Such questions can foreground what aspects of writing, programming, and interpretation we take as givens when constructing repositories.

While mostly gestural, I hope this snapshot adds definition to gitting the humanities classroom. I certainly realize that—as intimidating, exclusionary, or value-laden activities—Git, code, and the command line are not unique cases. Humanities practitioners may also observe how "high art," "difficult literature," and "complex theory" are culturally embedded and conducive to privilege, too. That said, like all contributors to "Hacking the Classroom" and against any claims for technological determinism, my pedagogy is premised on how technocultures are constructed and how they can be transformed.

The primary reason I git the humanities classroom, then, is to teach and learn both code and the command line from the inside, through a combination of media theory and computing practice. This hack is one approach to determining when (if ever) the programming hype is warranted, who it benefits, how it got that way, and how (where necessary) it can be revised or redirected. It also commits the humanities classroom to a curious yet timely social relation, where a control technology facilitates sharing and individuation at once, with a history. Such is the state of today's social networks.

Image below care of Melanie Yergeau

Melanie Yergeau

Disability Hacktivism

Disability activists take note: The hackathon is the new telethon.

Revulsion is not a traditionally favored rhetorical pastime. But if disability historians were to agree on anything, it would likely involve the word reviled modifying the word telethon. The disability telethon signals some of the most damaging of disability myths and figures. Enter the poster child, pitiable and helpless. Enter the celebrity spokesperson, saving the day. Enter cost-burden analyses. Enter pithy quips about the meaning of life and humanity (of which disability and disabled people do not take part). Enter the sad music. Enter the cure, the elusive cure, please fund the cure. Did we mention the cure?

Perhaps the most iconic of disability telethons is the MDA Labor Day Telethon, led by Jerry Lewis for 45 years, and no stranger to controversy (Zoglin 2012, n.p.). In advance of the 1990 telethon, Lewis infamously referred to wheelchair users as “half-persons” in a spread for Parade magazine. The following year, disability activists—many of them former MDA poster children, or Jerry’s Kids—orchestrated a series of protest actions under the banner of Jerry’s Orphans. Over a span of two decades, the protests received widespread local and national media coverage. Mike Ervin, Laura Hershey, Harriet McBryde-Johnson, and numerous other disability activists outlined the exclusionary practices in which Lewis and the MDA routinely engaged: from plainly stating that disabled lives were lives not worth living, to preventing disabled volunteers from working at disability summer camps (Johnson 2005), to focusing on the elusive “cure” at the expense of the needs, desires, and full participation of the people they claimed to serve.

Year after year, Lewis refused to back down, instead representing activists as bitter, greedy, and ungrateful. In an interview with ABC, Lewis heralded himself a hero, claiming that his celebrity appeal gave children with MD the will to live. When pressed about Jerry’s Orphans and his half-person commentary in Parade, Lewis responded, “They can’t run with me down the hall, can they? In truth, aren’t they given half?” And, in 2005, when an Orphans protest erupted at a promotional event, Lewis purportedly exclaimed, in anger, “These people are going to walk out of those chairs and walk home tonight. I bought those chairs for them.”

The MDA is not the first, nor the last, of problemed disability charities. Nor is the MDA my main focus here. But its story remains iconic because the rhetoric of the telethon is a rhetoric of charity and exclusion and infantilization. The rhetoric of the telethon denies the humanity and agency of disabled people, all the while reifying the prowess and kindliness of the presumably able-bodied.

This rhetoric, I argue, pervades contemporary discourses around hacking. We encounter charity-driven ideologies with the hackathon, which is in many respects a sexed-up version of the telethon. But we also run the risk of reinforcing such ideologies within our conceptions of hacking itself, especially where hacking-as-supposedly-activist-practice meets disability. In the paragraphs and images that follow, I maintain that hacking often signifies a telethon-esque logic. When hacktivism meets disability, we assume the logics of the fix, the cure, and the kind-hearted helper. Disability hacktivism, I fear, has become a shinier and hipper way of signaling the impoverished lives of the so-called cripples and feeble-minded. But, as I’ll also suggest, these rhetorical frames are not self-defeating: As crip activists and allies, we have the power to cultivate hacking into a disability-positive practice, one that takes participatory design as its charge.

Enter the Hackathon

Hackathons = the hipster version of telethons. For the benefit of those who do not self-identify as hipsters or hackers (or hiphacksters?), hackathons usually take form as hours- or dayslong computing events in which large numbers of volunteers seek to build products (virtual or physical) for a particular community. When disability or illness enters the fold, hackathons might result in blood-sugar management apps, or videogames that model how to interact with healthcare professionals, or vehicles that enable broader access for wheelchair users.

My argument here, then, is not that hackathons never produce anything “good”: rather, my argument is that disability hacktivism often excludes disabled people and considers disability as pitiable and in need of remediation. What follows are two such stories.

Story one. In February 2013, Hacking Health in Vancouver hosted a cross-disability hackathon that yielded a project called Auti-Sim, an autism simulation game developed by non-autistic people. The program was designed to emulate the sensory experiences of autism, which one reviewer described as a “playground nightmare” that was “a very short experience. But then, so is having a railroad spike driven into your ear” (Grayson 2013, n.p.). Tellingly, no autistic people were consulted in the design of Auti-Sim, which aimed to demonstrate the “horror” of the autistic sensorium (Grayson). When confronted with negative feedback from autistic people, lead designer Taylan Kay responded, “You can still learn something about your own condition, even if you have other experiences. It doesn't mean you know everything about autism just because you have it. . . . It's more of a statement on how bad it can be rather than how it is for everyone” (Orland 2013, n.p.).

Story two. In March 2013, the Bing Fund held an autism hackathon in Seattle. Notably, none of the organizers or participants identified as autistic. Promotional materials for the event flaunted loaded language, variously referring to autism as a disease and an affliction. When autistic bloggers contacted the organizers—angered, hurt, and concerned—they were ignored. The hacking went on as planned, all about autism but without autistic people.

What these two stories share is a common theme—the collective dismissal of disabled people. In flagrantly arrogant constructions, these non-autistic designers claimed to know more about the embodied experience of autism than autistic people. In fact, their impulse was to claim that autistic people’s knowledge about autism is inherently self-focused and idiosyncratic. If you’re autistic, they implied, then you’re only capable of making statements about yourself (and maybe not even that).

What to say about these technological impulses—impulses that assume disability is badness and horror, impulses that assume non-disabled people and technology are disability saviors? What to say about those who assume that disability represents the baddest of the bads?

My own position as a disabled activist has led me to engage with hacking under a troubled framework, through a complex (and vexed) set of histories. And, the gist of my argument is that we (as techno-rhetoricians, advocates, and citizens) not only need to be aware of these histories; we also need to work in service of disrupting hacking hierarchies and instead privilege the voices and desires of disabled people.

Hacking Bodies, Or: Passing, Fixing, and Retrofitting

In popular discourse on disability, hacking often resembles one of the following motifs:

  • Hacking as passing.
  • Hacking as fixing.
  • Hacking as retrofitting.

These ideas about hacking share a focus on the normalization of bodies. That is, they emphasize fixing, curing, and rehabilitating people, all in the name of normalcy.

Hacking-as-passing represents an attempt to appear non-disabled, an effort to avoid stigma and marginalization (Linton 1998). Passing as a term has a long history in marginalized communities, and originates beyond disability to conversations of race and sexuality. In short, passing means attempting to be that which you are not (Siebers 2008).

Of course, when we’re talking about medical discourse, disability represents something bad. It is pathological. It is something in need of remedy or cure. It shouldn’t come as any surprise, then, that many disability service professionals generally think of passing as a positive, as a stepping stone toward an idealized bodymind or “indistinguishability from one’s peers” (Alyric 2009). Passing is pervasive in clinical contexts. It’s what professionals want (and expect) from their clients.

Page from a journal article on autism and hacking
Page from a journal article on autism and hacking. The words hacking, mentalizing, and passers are highlighted in yellow to signify their relation to one another.

The above image is but one example of hacking-as-passing. It’s from a 1994 article in the journal, Social Development. In it, the authors describe how some autistic people can hack social cues and pretend to understand other people’s intentions. The key take-aways from this and similar representations are these: 1) disabled people should do their best to feign normalcy, and 2) disabled people, despite normative appearances, generally “fake” core attributes of their humanity (e.g., socialization, communication, or mobility).

What I’d like to direct our attention to now are hacking as fixing and hacking as retrofitting—because, like passing, both are rehabilitative in nature; both assume disabled people as passives and able-bodied people as savior-agents; both involve tinkering toward normalization. What separates them is this: fixing involves bodyminds, and retrofitting involves spaces.

Sreen shot of the Hacking Autism website
Screen shot of the Hacking Autism website. The banner includes the image of a bird freeing itself from a cage. The body of the site includes a banner labeled Hackathon, which is figured beneath the image of a hammer and wrench. To the right is a site headline titled “Help us hack autism: Hacking Autism is using technology to give people with autism a voice.”

Here, then, is an example of hacking as fixing. The above image shows a screen shot of the former Hacking Autism website, a collaboration between Autism Speaks and Hewlett Packard. Hacking Autism develops freeware apps that encourage social communication and discourage “problematic behaviors.” The site exudes the message that autistic people are enigmas in need of techno-enhancing. Even the site’s logo [that of a bird breaking free from a cage] rehashes the decades-old stereotype that autistic people are imprisoned in their bodies. The message throughout the site is clear: Autistic people need to be hacked. They are puzzles to solve, bodies to cure.

Like hacking-as-fixing, retrofitting also assumes an able-bodied default. And, when disability enters the mix, the idea goes, we need simply to add onto already-existing designs—this, rather than reinventing our social and material spaces (Dolmage 2008). Retrofitting is an additive, not re-imaginative, ideology. Rather than considering disability from the beginning of the design process, retrofitting instead tacks on hacks and fixes as an afterthought. In many respects, I would characterize retrofitting as an “oh shit! we forgot about you!” ideology.

Photo of a maze-like wheelchair ramp
Photo of a maze-like wheelchair ramp, a clear retrofit to an older building. Not only does the ramp have many twists, turns, and inclines; it is also blocked by a bicycle, which is chained to the railing.

The above image is a typical example of a retrofit. In it, a wheelchair ramp has been added onto a building. Clearly, this ramp is an afterthought, not something that was conceived at the inception of the building’s design. And typically, retrofitting means that if disabled people are involved in design, it is only at the very end of the process (if that).

And so, hacking suggests that retrofitting is a matter of tinkering with people and places until they fit "just right." Paul Collins (2008) captures this sentiment well, I think, with the following line: “the problem with pounding a square peg into a round hole is not that the hammering is hard work. It's that you're destroying the peg.”

Toward Criptastic Hacking

Even though disability hacktivism often takes form as something bodies- and pathology-focused as opposed to systems-focused, disability studies has long, productive histories of reclaiming language and contorting normative ideologies (Kuppers 2011). What we need, then, is a criptastic reclamation of hacking. A criptastic version of hacking is one that rails against forced normalization, one that moves from body-tweaking to something collective, activist, and systemic. I am asking us to imagine the possibilities if hacking were a disability-led movement, rather than a series of apps and patches and fixes designed by non-disabled people who cannot even be bothered to talk with disabled people.

Within this webtext collection, my co-authors have offered models and theories of hacking that subvert, dismantle, question, and reinvent many of our archly held notions about what hacking is and what social justice is and what it means to be human. When activists make claims about “hacking,” they’re suggesting we engage in activist work that goes against some kind of institutional grain. There is resistance and tinkering involved in any act of hacking. Hackers are makers (and sometimes breakers). As Elizabeth Losh (2012) describes it, hacking involves “the nonviolent use of digital tools in pursuit of political ends” (n.p.). Under such a framework, hacking might look like a class discussion in which everyone uses mobile phones or tablets to disrupt traditional modes of instruction. Or, hacking might involve rearranging furniture so that everyone can have the maximum amount of space to flap their hands and roll their bodies. Each of these acts—using iPads, pushing away desks—invokes a certain kind of politics, a politics that, for instance, values diverse styles of communication or ways of moving.

Why, then, have we traded in the disability activist for the disability poster child? What is it about disability that tends to make hacking so, well, special?

What if we were to think of disability hacktivism in a non-special sort of way? Instead of seeing it as something that is static, additive, or clinical, what if we viewed disability hacktivism as participatory and messy and dynamic? Jay Dolmage has often described access as a way to move. If access is a way to move—if hacking is a way to move—then, suddenly, we’re not focused on software and products and techno-cures. Rather, we are focused on process. We are focused on not only disabled bodies, but disabled spaces, and how bodies and spaces move and interact with each other. We are focused on work that never ends, because access isn’t an end goal. Access is a verb. Access is what we do, not what we are or where we arrive when the telethon ends.

Criptastic hacking, or hacking-as-moving, is disabled-led. By this I mean the following: Disability hacktivism is only ethical if it is led by people with disabilities. We are the movers, not the moved-upon. We are the ones who should be hacking spaces and oppressive social systems; we should not have our bodies and our brains hacked upon by non-disabled people.

The above doesn’t mean that there isn’t room for non-disabled people, or that non-disabled people are somehow exempt or prevented from doing the work of disability rights. What this does require, however, is a reorientation. It involves setting aside our most emetically cherished of disability tropes—heroism, pity, charity—or the celeb-righteous anger of buying chairs and ramps for “ungrateful half-persons.”

In sum, bodies are not for hacking. Bigotry is.

Image below care of Aimée Knight


anvc. Last modified 2014. scalar. https://github.com/anvc/scalar.

Ball, C. and Hawk, B., Eds. (2006a). Special Issue: "Sound in/as Compositional Space: A Next Step in Multiliteracies." Computers and Composition Online 23:3. Online.

____. (2006b). Special issue: "Sound in/as Compositional Space: A Next Step in Multiliteracies." Computers & Composition, 23:3. 263-298.

Balsamo, A. (2011). Designing Culture: The Technological Imagination at Work. Durham: Duke University Press.

Berger, J. (Director). (1972). Ways of Seeing: BBC [production company].

Bogue, Ev. (2013, December 12). "If You Don't Know Git, You Don't Know Shit." Retrieved from https://web.archive.org/web/20140502230021/http://evbogue.com/dontknowshit/.

Boler, M. (1999). Feeling Power: Emotions and Education. New York: Routledge.

Cartegena, A., Metcalf, C., Paese, A., Schneider, E., & Schuming, Z. (n.d.). Walker, Wisconsin Ranger. Retrieved from http://scratch.mit.edu/projects/cbmetcalf/2525385.

castiron. Last modified 2013. didh. Retrieved from https://github.com/castiron/didh.

Codecademy. (n.d.). Codecademy. Retrieved from http://www.codecademy.com/

Cohen, D. J. and Scheinfeldt, T., eds. (2013). Hacking the Academy: New Approaches to Scholarship and Teaching from Digital Humanities. Ann Arbor: University of Michigan Press.

Comstock, M. and Hocks, M. E. “Voice in the Cultural Soundscape: Sonic Literacy in Composition Studies.” Computers and Composition 23:3. Online.

Cox, G. and McLean, A. (2012). Speaking Code: Coding as Aesthetic and Political Expression. Cambridge: MIT Press.

Davidson, C. (2012, January 25). "Why We Need a 4th R: Reading, wRiting, aRithmetic, algoRithms." DMLCentral. Retrieved from http://dmlcentral.net/blog/cathy-davidson/why-we-need-4th-r-reading-writing-arithmetic-algorithms.

Dobie, S. (2007). “Viewpoint: Reflections on a Well-Traveled Path: Self-Awareness, Mindful {ractice, and Relationship-Centered Care as Foundations for Medical Education.” Academic Medicine 82:4. 422-427.

Dolmage, J. (2008). “Mapping Composition: Inviting Disability in the Front Door.” In Disability and the teaching of writing, edited by C. Lewiecki-Wilson and B. J. Brueggemann, 14-27. Boston: Bedford/St. Martin’s.

Faden, E. (2008). “A Manifesto for Critical Media.” Mediascape (Spring 2008). Online.

Frith, U., F. Happé, and F. Siddons. (1994). “Autism and Theory of Mind in Everyday Life. Social Development 3:2. 108-24.

Grayson, N. (2013). "Playground Nightmare: Auti-sim Is about Childhood Autism." Retrieved from http://www.rockpapershotgun.com/2013/03/01/playground-nightmare-auti-sim-is-about-childhood-autism/#more-143851.

Hacking Autism. Last modified 2012. http://hackingautism.org/.

Hacking the Academy: A Book CrowdSourced in One Week. (2010, May 21-28). http://hackingtheacademy.org/.

Harper, D. (2014, April 8). "Why You Should Learn Git." Retrieved from http://posts.danharper.me/why-you-should-learn-git/.

Haggard, D. (2011, April 9). "Why Everyone Should Learn to Program." Reviews in Depth. Retrieved from http://reviewsindepth.com/2011/04/why-everyone-should-learn-to-program/.

Hershey, L. (1993). "From Poster Child to Protester." Crip Commentary." Retrieved from http://www.cripcommentary.com/frompost.html.

hooks, b. (1994). Teaching to Transgress: Education as the Practice of Freedom. New York: Routledge.

Imrie, R. (1998). “Oppression, Disability, and Access in the Built Environment.” In The Disability Reader: Social Science Perspectives, edited by Tom Shakespeare, 129-46. London: Cassell.

Jackson, L. A. et al. (2008). "Race, Gender, and Information Technology Use: The New Digital Divide." CyberPsychology and Behavior 11:4. 437-432.

"Jerry Lewis speaks about the disabled and 'Jerry’s Orphans.'" (2009/1992). [Clip from ABC Primetime Live segment]. Retrieved from https://www.youtube.com/watch?v=5tM4tTUMwGE.

Johnson, M. (1992). "A Test of Wills: Jerry Lewis, Jerry’s Orphans, and the Telethon." Ragged Edge Online. Retrieved from http://www.raggededgemagazine.com/archive/jerry92.htm.

____. (2005). "Where Are the Orphans?" Ragged Edge Online. Retrieved from http://www.raggededgemagazine.com/blogs/edgecentric/archives//000627.html.

Joint Information Systems Committee (JISC). (2006). Designing Spaces for Effective Learning: A Guide to 21st Century Learning Space Design. Retrieved from http://www.jisc.ac.uk/uploaded_documents/JISClearningspaces.pdf

Karsdorp, F. and van Gompel, M. (2014). Python Programming for the Humanities. http://fbkarsdorp.github.io/python-course/.

Koslow, J. (2012). "What's the Pointe?" University of Southern California.

Kuhn, V. (n.d.). Courses—MAP@USC—University of Southern California. Retrieved from http://map.usc.edu/courses/.

____. (2012). "The Rhetoric of Remix." In "Fan/Remix Video," edited by F. Coppa and J. L. Russo, special issue, Transformative Works and Cultures 9.

Kuppers, P. (2011). Disability Culture and Community Performance: Find a Strange and Twisted Shape. New York: Palgrave MacMillan.

Lawson, K. M. (2013, April). "Resources for Learning Git and GitHub." ProfHacker. Retrieved from http://chronicle.com/blogs/profhacker/resources-for-learning-git-and-github/48285.

Linton, S. (1998). Claiming Disability: Knowledge and Identity. New York: NYU Press.

Losh, L. (2012, May 28). "Going Low-Tech to Teach New Literacies." DMLCentral. Retrieved from http://dmlcentral.net/blog/liz-losh/going-low-tech-teach-new-literacies.

____. (2012). "Hacktivism and the Humanities: Programming Protest in the Era of the Digital University." In Debates in the Digital Humanities, edited by M.K. Gold. Minneapolis: University of Minnesota Press.

Meneely, A. (n.d). "Know They Tools." Retrieved from http://www.se.rit.edu/~andy/must-know/.

Murphy, S. (2012). “Soundscape Analysis.” Blog post used with permission, personal communication.

Nakamura, L. (2009). "Don't Hate the Player, Hate the Game: The Racialization of Labor in World of Warcraft." Critical Studies in Media Communication 26:2 (June 2009). 128-144.

Orland, K. (2013). "Auti-sim Lets You Experience the Horror of Sensory Overload." Ars Technica. Retrieved from http://arstechnica.com/gaming/2013/03/auti-sim-lets-you-experience-the-horror-of-sensory-overload/.

Petitmengin, C. (2006). “Describing One's Subjective Experience in the Second Person: An Interview Method for the Science of Consciousness”. Phenomenology and the Cognitive Sciences, 5:3-4. 229-269.

Picard, R. W. (1997). Affective Computing. Cambridge: MIT Press.

Posner, M. (2012, February 29). "Some Things to Think about before You Exhort Everyone to Code." Retrieved from http://miriamposner.com/blog/some-things-to-think-about-before-you-exhort-everyone-to-code/.

Riggs, M. T. (Director). (2004). Ethnic Notions: California Newsreel.

Said, E. (1994). “Professionals and Amateurs.” In Representations of the Intellectual: The 1993 Reith Lectures. New York: Pantheon Books.

Selfe, C. (2009). “The Movement of Air, the Breath of Meaning: Aurality and Multimodal Composing.” College Composition and Communication, 60:4. 616-663.

Siebers, T. (2008). Disability Theory. Ann Arbor: University of Michigan Press.

Softley, I. (Director). (1995). Hackers: United Artists.

"Steve Jobs Says Everyone Should Learn to Program." (2012). Retrieved from https://www.youtube.com/watch?v=mCDkxUbalCw.

Stross, R. (2012, March 31). "Computer Science for Non-Majors Takes Many Forms." The New York Times. Retrieved from http://www.nytimes.com/2012/04/01/business/computer-science-for-non-majors-takes-many-forms.html.

Trinh, T. M. (Director). (1989). Surname Viêt, Given Name Nam: Women Make Movies.

Vasilescu, B. et al. (2012). "Gender, Representation and Online Participation: A Quantitative Study of Stackoverflow." 2012 International Conference on Social Informatics, Washington DC. 14-16.

Vitanza, V. and Kuhn, V. (2008). "From Gallery to Webtext." Kairos: A Journal of Rhetoric, Technology, and Pedagogy 12:3 (Summer 2008). Online.

Walls, D. M., Schopieray, S., and DeVoss, D. N. (2009). "Hacking Spaces: Place as Interface." Computers and. Composition 26. 269–287.

williamjturkel. Last modified 2013. Programming-Historian-version-1. Retrieved from https://github.com/williamjturkel/Programming-Historian-version-1.

Wood, M. (2005). "Jerry Lewis Unhinged." Chicagoist. Retrieved from http://chicagoist.com/2005/11/17/jerry_lewis_unhinged.php.

Wysocki, A. F. (2004). “Introduction.” In Writing New Media: Theory and Applications for Expanding the Teaching of Composition, by Anne Frances Wysocki, Johndan Johnson-Eilola, Cynthia L. Selfe, and Geoffrey Sirc, 1-44. Logan, UT: Utah State University Press.

Yang, K. W. (2009). "Discipline or Punish? Some Suggestions for School Policy and Teacher Practice." Language Arts 87:1 (September 2009). 49-61.

"You Should Learn to Program: Christian Genco at TEDxSMU 2012." (2012). TEDx. Retrieved from http://tedxtalks.ted.com/video/You-Should-Learn-to-Program-Chr.

Zitzlsperger, C., & Hagerty, M. (n.d.). Bully Be Gone. Retrieved from http://courses.jamesjbrownjr.net/interactive_fiction.

Zoglin, R. (2012). "Why Did Jerry Lewis Leave the Telethon?" Time. Retrieved from http://entertainment.time.com/2012/08/16/why-did-jerry-lewis-leave-the-telethon/.