Being able to think materially about material goods, hence critically, gives one some independence from the manipulations of marketing, which typically divert attention from what a thing is to a back-story intimated through associations, the point of which is to exaggerate minor differences between brands. Knowing the production narrative, or at least being able to plausibly imagine it, renders the social narrative of the advertisement less potent. The tradesman has an impoverished fantasy life compared to the ideal consumer; he is more utilitarian and less given to soaring hopes. But he is also more autonomous.
This would seem to be significant for any political typology. Political theorists from Aristotle to Thomas Jefferson have questioned the republican virtue of the mechanic, finding him too narrow in his concerns to be moved by the public good. Yet this assessment was made before the full flowering of mass communication and mass conformity, which pose a different set of problems for the republican character: enervation of judgment and erosion of the independent spirit. Since the standards of craftsmanship issue from the logic of things rather than the art of persuasion, practiced submission to them perhaps gives the craftsman some psychic ground to stand on against fantastic hopes aroused by demagogues, whether commercial or political. The craftsman
‘s habitual deference is not toward the New, but toward the distinction between the Right Way and the Wrong Way. —Matthew B. Crawford —Shop Class as Soulcraft (The New Atlantis)
I’m in the middle of a unit that’s causing some stress in my Writing for the Internet class. I’m asking my students to code simple HMTL pages by hand.
I love this group of students, and I’m sure they’ll do fine. But I find their struggles noteworthy, especially since our initial discussion of Vannevar Bush’s brilliant essay “As We May Think” focused mostly on how difficult many of the students found it to read an old-fashioned essay. (“Why did he go on and on like that? Couldn’t he have just given us the gist in a few sentences?”)
Through their blogs, the students have already had plenty of changes to write for online audiences. Asking them to code their own HTML will demand from them a deeper understanding of how technology affects our writing. When you code something by hand, there are no shortcuts; no resources that you can skim in order to get “the gist.” Since they are Humanities majors, they are used to earning grades by being bright, by innovating and improvising, and by having great ideas. They’re not used to being flummoxed because they used the word processor program that they were familiar with instead of the text-editing tool that I recommended, so that their code ends up with curly quotes that confuse the web browsers. For some of them, it’s a huge mental shift to keep them from habitually clicking on an icon to open the file. (If we want to edit an HTML file, you have to open it in a text editor, but clicking on it will open it with the default application, a web browser.)
It’s certainly not their fault that the GUI is such a part of their lives that they find this kind of coding foreign and unsettling. I am giving them lots of time to work on this, since I feel it’s very important for them to get under the hood of the web pages that we’ll be analyzing.
I did feel the HTML textbook I chose was very straightforward, with step-by-step instructions on what you have to type at each stage, but so far it seems the book lacks context (such as an introduction to the whole concept of icons and filenames and file extensions, which I’ve internalized because I used the command line interface for years before I ever touched a computer mouse). I’ve been able to supply that context after the fact, but the end result is still a bit of a disruption.
In grad school, I did computer programming on my own, for fun, because I found it personally rewarding to have a compiler tell me “45 errors” at 10:45am and to see that error list drop to 10, 3, 1, and finally 0 by the time I took a lunch break. There was no such software to detect logical flaws or factual mistakes in my literary analysis papers, which meant I had to develop a different mental model of what it means to “make progress” in my academic work. But I’ve found the methodical approach to bracketing a problem area and zeroing in on it is useful in any intellectual task.
If you have a 10,000 line computer code, and you work in one section at a time, changing one thing at a time, and trying to run the program after each change, you’ll always know what you did to introduce the error. If you work on multiple sections at the same time, making radical changes all the time, and you’re not methodical about checking your results, then you’ll have no idea what you did to cause the code to generate 467 errors, you’ll have no idea where to start looking for solutions, and you’ll be tempted to throw it all away and start over.
It’s okay to throw away a paragraph or a 1-2 page paper and start over, but it’s a huge waste of time to wait until your 5- or 10- or 50-page paper is beyond all hope, and then throw it all away.
Writing for computers (code) and writing for humans (essays) require different processes of drafting and revision, and the feedback loops are different. But in both cases, knowing the process is vital to generating a good final product efficiently. Crawford notes that the craft of wheel-making includes knowledge of what trees to fell, what time of year to cut them, and how to preserve the wood. While I don’t expect the students to be able to mine the raw materials to be used to construct the computers they’ll be using, I do feel they need to have more than a surface-level understanding of the medium they’ll be using.
Fortunately, I’ve built the “Writing for the Internet” course so that, at this stage, students aren’t being evaluated on the quality of the writing that they’re doing — right now, all they have to do is get the example website working, and they are free to work together as much as they wish. So, while the students have blogged about being terrified by HTML, the atmosphere during the workshops has been positive.
If you have a 10,000 line comptuer code, and you work in one section at a time, changing one thing at a time, and trying to run the program after each change, you’ll always know what you did to introduce the error. If you work on multiple sections at the same time, making radical changes all the time, and you’re not methodical about checking your results, then you’ll have no idea what you did to cause the code to generate 467 errors, you’ll have no idea where to start looking for solutions, and you’ll be tempted to throw it all away and start over.
As a now-experienced programmer, I definitely concur. This never goes away – no matter how much experience you have.