The data gathered for my dissertation will, eventually, have to be codified (organized in a meaningful way). Rich Rice suggested I use communications theory as a way of understanding what I find, whereas Fred Kemp (my dissertation chair) suggested systems theory. I’ve only looked preliminarily into those, but so far there’s nothing that suggests to me I could use them productively; however, there is one thing I’d like to comment upon.
Most theories I’ve encountered seem to try to account for static and dynamic, sameness and change, in some way. The communications theory I’ve read so far (and that’s not much) offers various metaphors for understanding communications between and among organizations: circle, star, etc., each figure accounting for power relationships and the supposed flow of information within that network. But there’s also an attempt to account for a change in state—what happens when the information is received, or how we can determine whether that information has been received and that therefore some sort of communication has taken place—that leads to speculation on the difference between organizations and individuals who stay the same and those that change, and what forms that change takes.
Systems theory (wherein I’ve read a bit more) is often an extended discourse on little but change itself: how the parts shape the whole, or the actions of the whole, or how understanding a system can change the system itself. . .on and on about static and dynamic systems. So, at the very least we can speculate that sameness and change are important to theorists in more than one area.
I’ve just read over Andrew P. McAfee’s “Enterprise 2.0: The Dawn of Emergent Collaboration” (http://bit.ly/ddzslZ) in which he defines Enterprise 2.0 along with six characteristics he’s identified as belonging to any technology that works as Enterprise 2.0. So, to begin, Enterprise 2.0 is "those platforms that companies can buy or build in order to make visible the practices and outputs of their knowledge workers" (McAfee 23). Earlier in the piece, he defines “platform” as a source of information in which “content is generated, or at least approved, by a small group, but then is widely visible” (22). So, to combine these two ideas, we might conclude that an Enterprise 2.0 platform is a method of communicating whereby a smaller group of people could distribute information to a larger group in such a way that the knowledge workers involved—whether the distributers or recipients—could see what others were doing and how they were doing it.
Into the mix goes McAfee’s SLATES acronym, which stands for the six components of such a system:
Search – “page layouts and navigation aids can help, but users are increasingly bypassing these in favor of keyword searches”
Links – “works best when there’s a dense link structure that changes over time and reflects the opinions of many people”
Authoring – “most people have something to contribute, whether it’s knowledge, insight, experience, a comment, a fact, an edit, a link, and so on. . .”
Tags – “don’t try to impose an up-categorization scheme; they instead let one emerge over time as a result of users’ actions.”
Extensions – computers using algorithms to suggest other content based on user behaviors. “Amazon’s recommendations were an early example of the use of extensions on the Web.”
Signals – pushed content
Each of these six components is based upon the idea of change: “bypassing,” “changes over time,” “something to contribute,” “emerge,” and then my own words “suggest” and “push.”
So, as a baseline, we can confidently claim that Enterprise 2.0 technologies are those which enable workers to (a) create, and (b) make visible not only what they’ve created but how they created it.
This model can be seen in how engineers communicate in the workplace: design reports, in particular, or even construction bids and statements of qualifications, almost never get their beginnings as a blank document. Engineers are always building (figuratively as well as literally) upon past documents and knowledge that others have created. Even beyond the rather simplistic view that engineering is based upon well-known characteristics of physics and chemistry, we can point to more subtle building blocks such as design projects done in the past which are similar to the one currently in the development stage. Building standards, such as LEED certification, ADA compliance, and EPA compliance exist prior to the design project, and thus the project itself is only part knowledge creation: it is in even larger part an effort at knowledge sharing and knowledge application.
In the technical writing class we use to prepare engineers for their future as knowledge workers who need to communicate with others, however, the knowledge is largely created (a) for that class as assigned by the instructor, and (b) by individual students. Thus, the knowledge management paradigm we see in writing in the workplace does not exist, or does not exist to the same extent, in the classroom.
Tuesday, March 30, 2010
Tuesday, March 2, 2010
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.
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.
Subscribe to:
Posts (Atom)