Humanities Instructors and Technical Students

The last couple of weeks have served to emphasize more subtly the differences between an object-oriented approach in a field like engineering and the people-oriented approach in a field like English studies. I saw “more subtly” because so many of those differences have been hammered home in the past, but my recent experience has been far more subtle.

I’ve been working with some ocean engineering students who are writing a methods section for a technical report. One of the lessons we’ve had to discuss has to do with passive voice. They’ve been told, over and over, never to write in the passive voice. They avoid it pretty consistently. They’ve also been told that a methods section is like a set of instructions for someone who wants to duplicate your work. Both pieces of advice are, in this case, incorrect and can serve to illustrate some of the challenges involved with teaching technical communication.

Writing instructors frequently tell their students to avoid the passive voice and use the active voice. There’s more focus on the doer of the action, and less focus on the objects of that person’s actions (which is presumably “better” because people are more important than objects). But engineering, and many of the sciences, in fact, are focused on things rather than people. Keeping in mind that the audience for a technical report is technical by default, writing with an object-oriented approach is the logical choice. Audience awareness is in fact a humanities-based approach, and if we humanities folks are going to work honestly alongside more technical disciplines, then we need to keep their audience firmly in mind.

Next, the purpose of a methods section is not so that the first person who reads your document can rush into the lab and duplicate the process. Instead, the purpose of a methods section is to create community (this is a hard one for the technical folks to swallow, but it’s true). Science is, methodologically speaking, a community project. Science assumes that there is a world external to each of us, that that world is shared in common by everyone, and that measuring that world can teach us something valuable. All of these assumptions mean that a good methods section should tell a precise story: what was done in the lab, how it was done, why it was done, and whether there were any variances in standard procedure (the word “standard” itself implies community knowledge creation). The methods section is a way for the engineer or scientist to become transparent to the larger community of technical activities, thus playing an important role in the ongoing conversation of scientific discovery. Without that methods section, the report separates itself from the transparency that makes science possible.

In explaining the purpose of a methods section, both technical and humanities personnel have a tendency to underestimate its role, and simply describe it as a set of instructions; thus, students often written in the present tense, as though they are telling someone what to do. This is, of course, a failure, since the point of the methods section is to build the author’s ethos and establish connections to the community, and that therefore the methods section should be past tense: the story of what was done in the lab.

Reading through an engineering writing assignment described in some FIE conference proceedings, I was able to clearly see the humanities influence in the design of the assignment itself. That humanities influence is often powerful and works well in an engineering communication course: there’s no reason to cut out audience analysis, rhetorical training, document design, and the like. However, the goal is to help technical professionals become better technical professionals. For the assignment description I read, the genre was listed as “research paper,” which from the start grounds the entire endeavor in the humanities. Much of the assignment, however, seemed like a good idea (again—using the humanities to teach engineering communication isn’t necessarily a bad idea): groups used individual critical analyses of sources to determine which topic would be their focus; groups used affinity diagrams to narrow their focus; groups were composed of both students and faculty; individuals were assigned tasks by the group; groups merged and revised documents together.

But the whole assignment is flawed from the beginning. The authors indicate that the engineers need training working in groups because as professional engineers they will be required to work in groups. But what the authors fail to do then is to find out what kinds of things engineers do in groups. For instance, when writing, engineers rarely start with a blank page or are allowed to decide upon a topic (or project) all on their own. Instead, engineers almost always have projects handed to them, and their writing almost always starts with boilerplate material based on building codes, specifications and standards, and written materials from past projects; thus, the brainstorming and individual research that went into this research paper does not, in fact, mirror the professional engineering writing experience.

I am not (yet) advocating engineering communication classes wherein students actually work with boilerplate material provided by previous classes (though that does sound intriguing) or that the above assignment is entirely wrong-headed. Rather, I’m proposing that humanities instructors who teach future technical professionals be aware of the differences in working environments and in disciplinary conventions that make technical professionals—often, though not always—so very different from the humanities.