Teach the Tech or Teach the Tools?
An annotated bibliography

With the annotated citations below I am attempting to capture at least some of the published conversation from the past decade or so around an issue which has proven rather durable in both "new media" composition pedagogy and professional writing. It can be seen a classic example of computing's religious wars (though rather more muted in academia than among the populace of general practitioners); or as the old tussle between scientific and romantic perspectives carried over into web design; or simply as a specific case of the ubiquitous question, for tool-using creatures, of how abstract we may properly make our tools — when we can allow them to be black boxes, and when their surfaces must be transparent and their inner workings revealed to their users.

That debate is the question of whether content creators for the web should have a thorough understanding of the technologies they use — HTML, CSS, and so forth — or whether it's acceptable for them to deal with those technologies (the "tech") indirectly and even in blissful ignorance of the details of their specifications and implementations, through higher-level software (the "tools") which presents a more abstracted view, often an ostensibly WYSIWYG one, of the material. I've framed this here primarily as a pedagogical question (hence "teach the tech", etc.), to give it a practical gloss rather than an ethical one — that is, I want to avoid letting the discussion degenerate into contention over the sins, real or imagined, of established practictioners. Casting it as a pedagogical choice lets us see it in terms of future options rather than present errors. But in reality this makes little difference to the main issue, because practitioners learn their craft somehow, and presumably we want pedagogy to reflect what we believe are best practices.

Of course as with all religious wars there is not likely to be a single satisfactory answers. There are any number of possible pat responses ("horses for courses", for example, or "the proof of the pudding is in the eating" — the right approach depends on contingencies of the situation, or the approach can only be justified by the outcome), but those lead to little useful insight. Similarly, there will be those who take a hard stance somewhere in the field and defend it against all comers; while that often does result in some interesting ideas, it moves us no closer to better action. Thus having reviewed these sources I now believe it is important to continually maintain a reflective and critical stance of any position on a question like this one; to both hold some (hopefully informed and sophisticated) beliefs about what makes for good web pedagogy and practice, and to continually review those beliefs in each new situation. We must remember that continual ideological vigilance is impossible and undesirable, and that all of us must work at multiple levels of abstraction. No one can consider simultaneously and continuously all of the interwoven technologies that go into building, serving, retrieving, and rendering web content — to say nothing of imagining and interpreting it. And by the same token, no web content is ever entirely original; we do not mint our own bits.

Summary of the Conversation

Early in this project I posted a query to the TECHRHET listserv, asking about sources on this question that subscribers particularly liked or felt should not be missed. At least one person noted that it would likely be hard to find academics arguing for the "teach the tools" position. And indeed I found far more arguments for the tech side. There are likely several reasons for this. One is that the tools are, at first glance, the easier option; certainly they let students produce their first work faster, they provide more integrated assistance, they offer instructors consistency, and they're more visually appealing to most users. Thus they largely make their own argument and there's little reason for an instructor to advocate on their behalf. More than that, though, academics are professional knowers of things, and what we might call the "code layer" of web documents is an ideal object of academic knowledge. It sits beneath the visible surface and determines much of that surface; it follows its own obscure rules; it takes the form of an argot for initiates. It's the hermeneutic filling in web-design cake.

Nonetheless, some academics do admit — often somewhat guiltily — that exigencies have forced them to rely on tools in the classroom. Sometimes that is because the instructors themselves lack the leisure to become experts in the technology. In other cases, it's because employment-oriented students insist on learning whatever is popular in the workplace, or because instructors believe that training students for the workplace is the correct ethical choice. (I hardly need note that this is a question of long tradition itself.) Or the course schedule may simply not have the time required to teach this material to students, many of whom are likely to find it rather alien and difficult.

It's worth noting, I think, that tool-based production is certainly in demand in the industry, as is training for it. The Association for Computing Machinery recently noted that its introductory course on Dreamweaver — likely the best-known WYSIWYG web authoring tool — is the ACM's most popular offering in its "Graphic Design" series ("ACM Member Technical Interest Service" email newsletter, February 2011). Since the ACM is a technical organization that caters to coders and scientists, this is not insignificant; it's likely that many ACM members, perhaps a majority, would disdain Dreamweaver and other WYSIWYG tools on principle.