As is typical for his blog, Tom Johnson has a great post that is asking us to consider a number of tech comm issues within a single question. It's one of the things that makes Tom's stuff interesting.
I want to respond to what I perceive as an anti-academic tone in Don Bush’s statements. In many of his early articles (raise your hand if you loved reading the “Friendly Editor” articles in Technical Communication), and particularly in his co-authored text, Bush takes an extremely pragmatic approach to the practice of technical communication. That’s what makes his writing so accessible. So why have I been so bothered since I (re)read Bush’s quotes on Tom’s site?
I’m not an academic. I tell myself that every time I step in front of pre-professional engineers and intend to impart some bit of practical knowledge about technical communication – some iota of skill that they can carry forward into their practice; making them exceptional designers, developers and communicators. I have, however, developed a deep appreciation for the way quality academic work serves and shapes the practice of technical communication. Tom’s simple question (Is rhetoric relevant?) exposes how so much of this work gets lost somewhere between the scholarly journals and field-level implementation.
I realize my perspective is skewed. I’ve had the advantage of continuing to practice tech comm while studying with some truly amazing scholars in Composition, Rhetoric and Technical Communication (Lipson, Phelps, Brooke, and Kennedy to name a select few). My intellectual development within these three incestuously related academic disciplines has nurtured my growth as a practicing technical communicator and editor. Through the hundreds (thousands?) of readings and my (notably weak) research projects, I couldn't help but recognize how much of my previous practice lacked the theoretical rationale that frames the problems technical communicators face and the methods we use to solve those problems. I've since realized the importance of including scholarly attention to a variety of theoretical and practical issues in my professional work, as well as using a broad range of methods and concepts. This understanding helps me bridge the gap between theory and practice; to simultaneously grow as a scholar and as a practitioner. And what’s wrong with that?
Scholarship is not a four-letter word, and the ivory tower is not as impenetrable as many practitioners would have us believe.
Friday, September 24, 2010
Thursday, September 23, 2010
i wanna easter egg
Problem statements are not easy to develop. I know this, which is why I try to instill in engineering students the importance of writing an effective and meaningful problem statement. And yet, there I was yesterday, in an initial project meeting, buying into a “client’s” list of wants, not needs. I walked out of the meeting convincing myself that we had to retrofit an existing workflow and series of business processes – and migrate 11 web sites to a new platform – to accommodate the client.
As TCers know, it’s needs on which we build our functional requirements; it’s needs that we vet, organize and rank to determine how we’re going to solve a client’s problem with an information product. It’s needs from which we create alignment (stasis) throughout the product.
By this morning I’d diffused the wants (and other extraneous commentary) down to a single, actual need. It’s a need that does not warrant anything close to what the client imagined, proposed, or expects. In fact, it’s a need – a real life business requirement – that is being met with existing workflows and information products. It’s just that the client is too clueless to understand this.
I’ll likely spend more time than I should documenting the actual problem and detailing the existing solution to politely convince the client he's missing the point. But that’s part of what we do, right?
Labels:
Business,
Higher Education
Tuesday, September 21, 2010
the greatness of anology
This has to be the funniest thing I've read in a long time.
Stuff like this makes me miss freelance work. Oh the fun you could have with a quote like that.
"... mobile manufacturers who go the Android route are doing no better than Finnish boys who pee in their pants for warmth in the winter."For context, see engadget.
Stuff like this makes me miss freelance work. Oh the fun you could have with a quote like that.
Labels:
writing
Monday, September 20, 2010
do what now?
I think I'll start collecting these to use in WRT 407 and WRT 307. I'll call the collection, Guess What They Really Mean To Say. Kind of catchy, right?
Long live Bill Lutz.
Egregious statement: "... support cross-campus generation of knowledge, enhancing the value of local research by exploring its trans-local ramifications."Holy academic blather Batman! It's not really important to note who made the statement. It is, however, important to note that the statement is part of a call to action document. I'm still trying to decipher what that call is, but I'm getting closer.
Long live Bill Lutz.
Labels:
writing
Wednesday, September 15, 2010
ee humor (barely)
I just ran across this at xkcd. I thought the EEs in WRT 407 would get a kick out of it. I barely get the joke, which is only a little pathetic on a few levels.
Labels:
Technical Communication,
technology
Monday, September 13, 2010
spoon full of sugar
I do this every year. I tell students that I’m not going to spend an inordinate amount of time on grammar because, goddammit, it’s an upper-division writing course and they should know this stuff by now. I then find myself including blather like this in my comments to a student’s submission:
What I should be helping these students do is recognize when something is amiss in their writing and then rely on the handbook or style guide to confirm the hunch. I don’t want to teach grammar and I don’t want pre-professional engineers to hate writing because they hate grammar. The trick is sliding it in without them knowing it – like when you have to mash up your dog’s pill and sprinkle it into his bowl of Chick-O-Beef parts.
The nasty little grammar pill. Bad medicine that, once taken, tastes oh so good.
... My only comment is in regard to the use of "and/or" in the last sentence. "And/or" means that either both circumstances are possible or only one of two circumstances is possible; however, it tends to be clumsy and awkward because it makes the reader stop and puzzle over your distinction. The more of these “stop signs” we have in our documents, the less effective the documents become as the reader’s frustration with the content increases. Another problem is that too many writers use "and/or" inexactly, so you may have a reader looking at your usage and thinking, “Well, that’s incorrect because I use and/or differently.” Again, this is a pause that pulls the reader out of the text to reconsider not what you’ve written, but how you’ve written it. The best thing to do is recast the sentence to be more precise and avoid confusing your reader with the awkward “and/or” construction.I couldn’t leave it alone. It’s like a pin in my neck. The funny thing is, it’s completely naïve of me to tell students they should know this stuff by now. The fact is, the majority of people hacking out technical and business documents don’t know this stuff by now, so why should college seniors? Hell, I barely know this stuff and I'm pretending to teach it.
What I should be helping these students do is recognize when something is amiss in their writing and then rely on the handbook or style guide to confirm the hunch. I don’t want to teach grammar and I don’t want pre-professional engineers to hate writing because they hate grammar. The trick is sliding it in without them knowing it – like when you have to mash up your dog’s pill and sprinkle it into his bowl of Chick-O-Beef parts.
The nasty little grammar pill. Bad medicine that, once taken, tastes oh so good.
Labels:
Technical Communication,
writing
Thursday, September 9, 2010
coming back: what's new
There's always plenty to say, just never enough time to say it. That's not entirely true, but it's an easy colloquial excuse.
WRT 407 started last week. I love teaching this course. This year, the College of Engineering is up for ABET re-accreditation. The last time we went through the process, the ABET reviewers were thoroughly impressed with the embedded nature of the writing instruction in WRT 407. Yet as I review the list of materials I need to provide to the reviewers this time, I'm struck by the request for an assessment summary. I don't recall how I handled this the last go around -- or if it was even requested.
Writing assessment, and the range of emotional responses it generates, continues to be an interesting topic. To meet the ABET requirement, I'm considering focusing specifically on the prevalence of genre in WRT 407 instruction. When I peel away the onion skin, assessment in WRT 407 is conducted exclusively through a review of each student’s work with a range of engineering and technical genres. Students work with different genres in highly contextualized instructional spaces to expose the differences among document types, while reinforcing the many types of associated writing requirements and activities they will encounter as practicing professionals.
I've blathered about this before, but I'm coming back to it now as another means of validating the design and pedagogical strategy we've adopted for WRT 407.
There will certainly be more on this later. It's preoccupying too much of my time for it not to be a series of boring blog posts. But not that there's anything wrong with that.
WRT 407 started last week. I love teaching this course. This year, the College of Engineering is up for ABET re-accreditation. The last time we went through the process, the ABET reviewers were thoroughly impressed with the embedded nature of the writing instruction in WRT 407. Yet as I review the list of materials I need to provide to the reviewers this time, I'm struck by the request for an assessment summary. I don't recall how I handled this the last go around -- or if it was even requested.
Writing assessment, and the range of emotional responses it generates, continues to be an interesting topic. To meet the ABET requirement, I'm considering focusing specifically on the prevalence of genre in WRT 407 instruction. When I peel away the onion skin, assessment in WRT 407 is conducted exclusively through a review of each student’s work with a range of engineering and technical genres. Students work with different genres in highly contextualized instructional spaces to expose the differences among document types, while reinforcing the many types of associated writing requirements and activities they will encounter as practicing professionals.
I've blathered about this before, but I'm coming back to it now as another means of validating the design and pedagogical strategy we've adopted for WRT 407.
There will certainly be more on this later. It's preoccupying too much of my time for it not to be a series of boring blog posts. But not that there's anything wrong with that.
Labels:
process theory,
Technical Communication,
writing
Subscribe to:
Posts (Atom)