(A repost from my blog.)
I've often wondered if the programmer culture -- stay-up late, code until you drop, rejoice when it works work ethic -- has been heavily shaped by the compiler. After taking an intense programming class in Java, I became well acquainted with the "Compile" button. For those not familiar with the function of compiling, it serves as the means for the computer to turn the particular source code in any higher-level programming language (Java, Python, Perl, C++, etc.) into machine-readable binary, (i.e., 01011101, on/off). Essentially, it's the method by which programmers are able to understand what the machine needs to run the program.
And through this process, a programmer learns that the machine is unforgiving and the programmer must be/come relentless. In object-oriented programming, a programmer's algorithm, i.e., an abstract process put into action in a specific context, must line up with the rest of the definitions, objects, and methods put into action throughout the rest of the program. If not, after pressing the "Compile" button, you receive any number of error messages that (try to) help you diagnose the problem-type and location.
Personally and frequently, I cursed my "frackin' machine" for not compiling, and I don't think this is an uncommon practice. Countless hours must be spent, attempting to finish a relatively complex program. These harsh demands of time and energy are expected when one takes on the task of writing a program, and these expectations carry over into a programming class at the university. As a composition instructor, I will admit that I grew jealous of the machine, but moreso these expectations that a teacher could establish and <em>students would accept</em> (most begrudgingly, of course): that it just takes time and energy.
I would argue that the essence of composing a computer program bears many of the same moments found in the writing process. Yet, unlike programming, the compiler button isn't so readily available. Seymour Papert argues that constructionist principles enable people to learn how to learn by taking abstract ideas "'in the head'", and then supporting it through the construction of anything, whether "a sand castle or a cake, a LEGO house or a corporation, a computer program, a poem, or a theory of the universe" to be materialized "'in the world'" (The Children's Machine 142). Papert continues by saying that after the ideas have been put into some material form, "the product can be shown, discussed, examined, probed, and admired. It is out there" (ibid). Once we write something, in whatever type of media, our thoughts and ideas have been put into a material condition, where it can be interrogated by ourselves or others. As a composition instructor, particularly of a FYC course, I find that students don't spend much time developing their texts, pressing the proverbial "Compile" button. (I know that I'm not alone here.)
The expectation to wrestle with one's own writing isn't an expectation shared mutually by teacher and student in the writing classroom because their isn't an intermediary machine telling the student, "Dude, that string of logic won't fly." Now, I'm not suggesting that semantic analysis programs are the answer to solve the problems of relieving the so-called "drudgery" of the writing process, because the early days of the Computers and Writing community tried to go about that task to no avail. That's not my point here. I think the inherent problem here rests on the fact that in the university classroom, teachers are seen as the compilers. We, as teachers, have to provide the go-to source for feedback, because we assign the grades. This is the expectation, but we cannot devote that time and energy to "compile" our students' writing. Despite the need for students to receive that kind of feedback from a go-to source, it's just not feasible, so the expectation for a writer to work on the text incessantly, just as a programmer is to do with his/her program, becomes effaced from the process.
This is not to say that there are singularities in programming, where style and efficiency in the logic of the source code don't matter, because, remind you, there is a human audience as well; hence, the term "clean code". But, I'm focusing on the sheer amount of work expected to complete a program in a programming class versus a text in a composition classroom. If we could somehow manage to have our students seek out, or even realize the potential of creating more viable "compiler" moments to discuss, probe, or admire their text in progress via people who are credible and relevant to the context, I would hope think that they would learn more nuanced notion of writing through such a process. But, in the end, teachers just don't make for good compilers. At least in the prevalent role of the teacher in the university.
Most students perceive only one authority, one compiler, so to speak: the teacher. They will challenge, question, poke, and probe the parameters of the assignment requirements, which are easy things to challenge in- and outside of class. The difficult processes of writing happen as writing happens, but we can't, nor should we always be there. (See a great post by Ian Bogost on the virtue of long compiles.) Yet, at least the compiler solicits the programmer to trudge onward, and unforgivingly so, because the work is not complete. And, so now I wonder, what could help students create these programmer-like time and energy expectations?
Papert, Seymour. The Children’s Machine: Rethinking School in the Age of the Computer. NY: Basic Books. 1993. Print.