TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
In fairness to Edmond Weiss, he did point out in the book that he wasn't really distinguishing between "artists" and "engineers" -- in fact, many engineers are artisans, or adopt the engineer-as-artist attitude, for example hoarding code or, in a more positive characterization, being proud of the creative aspects of their work, as in, as you say, the "poetry of code."
I believe what he was doing was trying to identify two processes, and two mindsets, and the best way he came up with to characterize them was the writer-as-artist (think "artiste" or "auteur"), versus the writer-as-engineer (more of a systems approach). One way is full of ego, and the other way sets aside ego in favor of the larger goal.
Sorry I didn't make that distinction earlier. In all honesty, I'm still working through the book. :) It's a book you have to really study, and read several times. And by the way, the book itself (as Paul Hanson pointed out) is a model of the structured writing, or topic-based writing, that it propounds -- back in 1985. Each topic stands alone as a nugget of thought, like an encyclopedia article. And yet taken together, they form a chain that unfolds into a kind of symphonic adventure with an expanded, elaborated theme where everything going forward supports the larger theme. Sounds a little heady but it's really a magnificent work. But, as with any work, you have to set aside the time to "consume" it.
Steve
-----Original Message-----
From: Mark Baker [mailto:mbaker -at- analecta -dot- com]
Sent: Friday, October 21, 2011 1:37 PM
To: Janoff, Steve; techwr-l -at- lists -dot- techwr-l -dot- com; 'PeterNeilson'
Subject: RE: Original work [was RE: STC certification program: skepticalcurmudgeonlyness, part II]
Steve Janoff wrote:
> I think folks are confusing the point of my post so let me first say
> what the post was *not* about and then what it *is* about:
Sorry Steve, I wasn't actually referring to your original post, just to the references to plagiarism that had entered the thread. Your point in your original post was a good one, though, and deserving of comment.
> 2. Weiss talks about two cultures of tech writers: the
> writer-as-artist, and the writer-as-engineer.
I think I largely agree with Weiss, but with a fairly significant caveat.
The problem I have with his distinction is that seems to oppose art to engineering, and to suggest that engineering is not creative. Nothing could be further from the truth. As the Wordpress folk like to say, code is poetry. Engineering is a creative discipline, and great engineers show great (an non-quantifiable) creativity.
Still, Weiss is right about there being two cultures. I would simply classify them as writer-as-artisan and writer-as-engineer. Both the artisan and the engineer can be creative. The difference is that the engineer makes a disciplined use of tools to expand the scope of his creativity and unite it with the creativity of others to achieve things that the artisan simply cannot accomplish.
> So a question comes to mind: When a software developer goes in for an
> interview, what does he/she say when asked what he/she has worked on?
> What would a software developer "show"
> as work? What if the person worked on a huge project as part of a
> large team, was an important part of the project, but couldn't really
> point to any particular code as being his or hers?
I think the answer to that question is that you simply don't ask that kind of question when you are interviewing for an engineering position. In discussing many of the projects I have worked on I say "we" most of the time, because "we" is the apt word to describe what was accomplished, and how it was accomplished. As far as I am concerned, a person who can talk intelligently about what the team did, rather than what they did individually, is demonstrating that they can be an effective team member, and if they are an effective team member, what does it matter what they can do by themselves?
> The question is really this: In moving to the writer-as-engineer
> paradigm, which seems superior (and is happening anyway), how do we
> move to more of a developer's style of presenting our work over the
> course of a career?
Perhaps you have to look at it like this. You can throw a log across a stream and say, I designed and built that bridge all by myself. Or, you can be part of huge team of specialists in many disciplines that designs and builds the Golden Gate Bridge, and say, I helped to build he Golden Gate Bridge. Which claim is more impressive?
I understand that you were not intending to address the certification issue per se, and I will only add a little bit on that subject. Everything I saw in the certification packet looked to me to belong to the artisan model.
That may be a fair reflection of where many people are in tech writing right now. But, like you, I feel that the advantages of the engineering model are so compelling that sooner or later people will have to switch in greater numbers.
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
