Monday, June 6, 2011

I Want to Go To There: The (Technical) Code

One of the more important ideas that drives my own scholarly practice - teaching and research - in the area of technology is an idea that was born from several of the theorists' work in our "Critical Perspectives" category. Feenberg, Winner, along with others like Donna Harraway helped me to understand that interacting with a specific technology is also engaging a system of ideas, sometimes made concrete, held by those who created, maintain, regulate, and others who use that technology.
"Traffic Light" by Flickr user mezzoblue

Driving a car in the U.S., for example, involves not only interacting with the ideas - made manifest - of those who designed and built the car, but with traffic laws, traffic signals and other associated technologies, and with a set of less formalized but no less material practices that relate to the culture of driving a car: how far above the speed limit can I go before I endanger anyone or before I trigger a police officer to stop me, how far can I travel without filling the tank, how do I express gratitude for another driver allowing me to make a lane change during rush hour?

These things are not separate from the technologies we use. They are part of them. Feenberg suggests that we think of technology as consisting of two mutually constitutive elements, then: 1) the technical artifact, and 2) the technical "code." Change one, and the other is likely to change. Install a technical object into a specific use context, and it remains unfinished - not yet fully "designed" if you will - until a technical code grows up around it to help define what it means, how it will be used, etc. The technical code, moreover, is less likely to reflect the specific views of a specific designer and more likely to be a combination of beliefs - some reinforced with authority such that they become laws or rules - representing many groups including those who use as well as those who make technological artifacts. At times, the technical code can work to productively re-define a technical artifact in terms of use in ways that contribute to broader participation, expansion of civil rights, or social justice. Feenberg calls these instances  of "subversive rationalization."

As a teacher, I could see that the technical code that co-exists with and shapes the use practices of educational technology can - and maybe even often do - have the same character and force as my own pedagogy. That is, a technology in my classroom can be teaching my students something about writing or reading or researching at the same time I am trying to do so. And we may not always agree with one another!

A favorite example of mine is Microsoft Word. I might ask students to use a freewriting exercise as a way to begin brainstorming ideas for a paper. You know: "write whatever comes to mind for 15 minutes without stopping; don't worry about it making sense or making everything correct, just write to see what comes out." A student fires up MSWord and starts. And then they see something like this:

Screenshot: MSWord tries to correct my spelling while I am freewriting
Word has a different message for my student. With the red squiggle under the typo "evetn," MSWord is whispering to my student: "hey, I think you misspelled something!" Note that it doesn't say "good job on the freewriting task!" Rather, it ignores my explicit instructions to the student to disregard spelling and tries to correct the student. Just who is supposed to be teaching this class, anyway!?

You see the point here. A classroom full of technology is also full of a whole range of pedagogical views about how best to do and how best to learn writing, not to mention who should and shouldn't be writing in the first place (password denied!). These views may reinforce or act in ways complementary to those of the teacher and students, and they may directly clash with them.

As teachers, we can't always take control of the design of technological artifacts. But we can - and I would say that we must - exert some influence in the design of the technical code, attending to those aspects of technology in particular that bear on our pedagogical aims and students' learning goals and strategies.

2 comments:

  1. Following the example of freewriting in Word, how have you found ways to "exert your influence in the design of the technical code," in this case influencing your student's ability to work past Word's attempt to subvert the freewriting exercise?

    ReplyDelete
  2. Good question! With that particular issue, the solution is to change the default settings in Word for a particular freewriting session so that it does not highlight grammar or spelling errors on screen. By default, both are turned on. In a computer lab where the version of Word and default settings are often established by a computing group on campus rather than a teacher, this type of configuring may need to be done at the beginning of every class (because settings revert to defaults when students logout).

    ReplyDelete