Re: Writer vs Author (was Techwriting after the boom)

["Bonnie Granat" <bgranat -at- editors-writers -dot- info>]

----- Original Message ----- 
From: "Andrew Plato" <gilliankitty -at- yahoo -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Sent: June 08, 2003 05:07 PM
Subject: Re: Writer vs Author (was Techwriting after the boom)


>
> "Bonnie Granat" wrote...
>
> > All of the technical occupational descriptions provided by government, by
> > private industry, and by the educational establishment state *primarily*
that
> > technical writers *explain* technology or scientific concepts to a lay
> > audience. There is no occupational designation for technical author. I
> believe
> > that that term is now used to distinguish between technical writers and
SMEs
> > who write books and articles. That leaves technical editors (like me, when
I
> > wear that hat) in the clear. ;)
>
> Traditionally, any human who called themselves a "writer" was the author of
> some material.

Yes, of course. Technical writers write. I am not saying they don't. However,
we do have two distinct terms, technical writer and technical author, and they
are distinct terms because they mean different things. In other words, they
are not synonyms. A technical author is an SME who writes and gets a by-line
or other credit. Technical writers do not get by-lines or any other credit, as
a general rule. Technical authors have a high public profile. Technical
writers are anonymous. Technical authors are like the guy I caught stealing
text from more than ten other people last month. Technical writers don't
steal.

Aside: I've often wondered if the quality of docs would improve if we all had
to sign them. ;)


Presumably, for a profession obsessed with words and their
> meaning  If you want to redefine the word "writer" that's fine with me. But
I
> don't think many people would agree with you. And I am almost certain that
> non-writers feel
>

I'm not redefining the word at all. I did not ever even suggest that technical
writers don't write. I said quite the opposite, in fact.

> > As I've said before, in other posts, there are no doubt certain technical
> > writing jobs that require a depth of understanding that is quite high.
>
> Yeah, the ones where excellence and quality are required.
>

One can write with excellence and produce quality if one knows the product and
can explain it to others.

> > yes, the more you know, the better. But technical expertise is simply not
a
> > requirement.
>
> So...
>
> Technical knowledge is preferred, but some places will settle with a writer
who
> has less. So it goes to follow then that those "writers" who are second
rate,
> get lower respect, lower pay, and less opportunity.
>

Aside: Respect begins with treating others with respect. Respect is not
something that your job description entitles you to.

I am a first-rate writer for a lay end-user. I am a fourth- or fifth-rate
writer for a developer. Were I so confused as to offer myself to the
programming audience as a writer, I deserve very little in the way of pay and
the company that hires me is out of its mind.


> I think that's pretty much accepted as fact. If you have tech skills, you'll
be
> employed longer, make more money, and have more opportunities. The more you
> know, the better. If you overtly choose NOT to become more technically
> oriented, your options and pay will be reduced accordingly.

I can agree with that.


>
> > The ability to write coherently *is* -- and as I've said, I find
> > bad thinking and bad writing to be the primary cause of bad documentation.
>
> Readers (real ones, not STC judges) assess the quality of docs based on
> primarily its content and partially on design. Readers are usually willing
to
> overlook bad design and grammar if the information is valuable.
>

I don't trust the technical content of a badly designed, badly written
document, and I think one is a fool to do so. Logically, it is absurd.

> Thus, when documentation is bad, it is most likely due to incomplete or
> inaccurate content. Grammar, layout, use of pronouns while part of that
> picture, are arguable a more minor issue. One that shouldn't even be an
issue.
>

You may trust such documents, but I don't. On what basis does one trust the
technical content offered by a company that cannot even write a coherent
sentence. How can one extract any value from the blithering of idiots?

> To person who edits (like yourself Bonnie), its natural to see bad
> documentation as a function of bad grammar/layout since. Editors don't have
to
> deal with content issues very much. As such, content won't seem like a
> priority.
>
>

But as I have made abundantly clear on several occasions, as an editor I was
intensely involved in content, so much so that I knew the product better than
the writers.

 Its like the old saying "to a hammer, everything looks like a nail."
>
> To readers, grammar & design are nice, but ultimately incidental. Content is
> what really matters. To a reader, the problem with bad docs is bad writers.
> They don't think about management issues or the fact that the writer
couldn't
> get a seat at the table in development meetings. As far as the reader cares,
if
> the docs suck, its because the author sucked.
>

Yes, content is what matters, but badly written content is bad content.
It is the writer's fault, for sure. But it's also the company's fault for not
caring.

> These realities might be unpleasant. But, when you see tech writing from
> outside the profession, as I have, you gain a much different perspective.
Some
> attitudes among writers (like relying on SMEs for all content) are seen in a
> far different light outside of STC meetings and tech writer listservs. I
know
> this because I've worn a lot more hats that just tech writer.
>

Relying on SMEs for all content is what I would say is NOT technical writing.
Relying on SMEs to clarify some aspects of a product's functioning is
appropriate for a technical writer.

> Now, you can poo poo my perspective and (like some other people here) just
> berate me for misunderstanding you. Or, you could acknowledge that  have a
> different perspective. And I know that most people outside of technical
> communication profession don't have a very high opinion of tech writers. And
it
> isn't because those writers couldn't write. It is almost always because the
> writers didn't understand their own material. From the conversations I have
> with CIOs and other executives, the consensus is - we want tech writers that
> are technical.
>


I have no problem with that. It's entirely appropriate for technical writers
who are documenting databases to know about databases. That such a statement
is even necessary seems silly to me, unless the company says it will teach me
what I need to know about databases. The key for me is knowing the product. In
each situation that will mean something slightly different. There are some
technical writing jobs into which I could easily move smoothly and without a
great deal of technical knowledge. There are others that I would not even
think of applying for because I lack the technical knowledge.


___________________________________
Bonnie Granat
Granat Editorial Services
http://www.editors-writers.info




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Robohelp X3, from eHelp, lets you quickly and easily create 
professional Help systems for all your Windows and Web-based 
applications, including Net.

Buy RoboHelp Office X4 by June 13th and receive
$100 mail-in rebate, Plus FREE RoboHelp Plus Pack.

Order RoboHelp today: http://www.ehelp.com/techwr-l

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.