Blog Post

Composition Teachers Make for Bad Compilers

(A repost from my blog.)

Compile Process

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.



My friend John Martin has extolled the virtues of writing in a markup language like LaTeX here:

After a few months of writing in Latex, I completely agree. The compile times aren't super long but can be up to a few seconds. Being able to type formatting along with content allows me to not break my focus as I write (especially when I need to type equations but also for plain old prose).

I write using Sublime text. John uses Vim. Neither one of us would call ourselves programmers primarily, but we love using programming tools for our writing.

I actually need to get John to teach me BibTeX. I have most of my Proposal written in LaTeX but haven't learned how to write a bibliography in it yet :)


I need to modify the APA6 repository bib style files so that they will output an annotated bibliography. If you would like, I can bring you in on this. This sort of thing is not about being a programmer. It is about finding and forging tools to do the things that you don't want to do manually. I can't imagine compiling and editing a bibliography manually anymore. In fact, it's scary to contemplate, since I have switched fields and we use APA in this one. I have no experience with APA. The only reason that my papers look right is that LaTeX and BibLaTeX have my back. 


APA annotated bibliographies here we come.  


Thanks to your open workflow I can poach your templates whenever you're done.  When are you going to make them forkable? :)


Love it, Elliott (and John)!

I read about LaTeX a few months back and thought it looked great for streamlining these tasks, but haven't had time to take the plunge, so to speak.

Instead, I just recently relaunched my site with a blog hosted at github using markdown. I am trying to post everything there with semantic tagging (class and reading notes, conceptual posts, etc.), so I can better prepare myself for when I do my comps/exams. :-)

Now that I hear some good feedback for LaTeX, I think I'll check it out this summer. Do you guys recommend any tutorials/resources to watch/read? Also, have you considered using it in the classroom, if you teach?

Regarding this post, I've thought about also incorporating markdown-based blogs that are hosted on for a tech writing course. This way, feedback and versions of student writing are all visible to the students, but I haven't had time to put together the proper materials to introduce such a system to students within the first 2 weeks of a course--quite the learning curve!

Thanks again for the comments!


Chris, I can't recall any good resources in particular, but a good editing and compling environment is essential.  TeXShop's interface can be a start.  But many then move on to using a software text editor, particularly if that's what you use anyways.  John uses Vim and I use SublimeText, which has a great set of plugins.  The literal write-compile workflow is amazing.  Seeing your document (in PDF form) get built incrementally from what uyouv'e written feels great.


Screencast on using SublimeText for this here:



I've memorialized John's annotated bibliography contributions as they stand now here.  Scroll down for the good stuff.