(final post for 5371, Foundations of Technical Communication)
Looking over the entire set of this week’s readings, both academic and reflective, two major elements or characteristics of TC stick out to me—two aims, to use Kinneavy’s term: an emphasis on reality as the primary element of the communicative situation, or an emphasis on audience as the primary element. In both, we can see why praxis (rather than just theory or just practice) makes sense as an approach. It’s easy to be theoretical and think about audiences and rhetorics; it’s easy to be practical and focus on practices and definitions, but the communicative act responds more kairotically than that. In turning TC into an object to be defined, we avoid its nature—so clearly shown in even a cursory overview of Writing A Professional Life—as a highly variable communicative problem-solving activity. TC is less a discrete set of genres, subjects, and styles of writing (though there are definitely safe genre claims and traditional ‘centers’ for TC as a field), but rather a set of motives for communication—a clear, if not always descriptively useful, perspective on a pretty messy discipline. (Me, First Post for this Course)
So, What Is TC? As a doctoral student who identifies much more with the R side of our TCR program, this is a question that has bugged me off and on in the last few years. It’s bugged me as a term that I honestly hadn’t given all that much careful thought to—so much so that if you’d asked me what TC was, say five years ago, I’d have probably given you a dirty look and rambled about memos and “professional writing,” what a lot of TCers would most likely refer to as “business communication” and not TC. It’s also bugged me as a term that, now that I’m IN a Ph.D.-granting program that is focused on technical communication theory and practice—and not as a sidereal interest within Writing Studies writ large, but as the primary reality of the program—I’m not able to give much better of a definition. Oh, sure, I’d be able to talk much more carefully and thoughtfully about the truly ‘technical’ or technology-related aspects of TC as a discipline and a set of practices; but a definition? Still eludes me.
Part of this elusion is because I’ve recognized that TC is more an activity than a discipline—the job titles and hardware/software packages may change, but the work is still the same. The Lukens book helped quite a lot in gaining this perspective—that TC in any form is communicating a complex process to a distant and ever-widening audience. This can take place in any number of genres, styles, and modalities, but the underlying activity of “making stuff make sense to people who it won’t make sense to otherwise” is the same whether it’s a furnace journal or a PowerPoint.
I note that in my first post, I very badly defined TC as “a highly variable communicative problem-solving activity.” Though certainly descriptive, not at all definitive. Bad technical communication, we might say. One of my other major claims is that technical communication emphasizes both reality and audience as a co-primary element of the communicative situation. That is, TC exists because of a complex reality. Yet that complexity only exists because of the relationship between reality and audience–usually a distant one, which is what necessitates the intervention of the technical communicator in the first place.
Personally, I’ve come to really like Carol Johnson’s definition of technical communication—the one that she gives in a video from her faculty website. “If it’s technical, and it’s communication, it’s technical communication.” It’s a pretty solid two-parter. If it’s got to do with technology, and if it communicates that technology, it’s TC, whether it’s in, on, or beyond the machine itself. It’s not fancy, but it works.
And THAT, I think, is the essence of TC. A text that works.