Re: Value of technical writers - Sorry, boss is (mostly) right

Subject: Re: Value of technical writers - Sorry, boss is (mostly) right
From: "Steven J. Owens" <puff -at- NETCOM -dot- COM>
Date: Wed, 30 Dec 1998 00:27:34 -0800

Andrew Plato writes:

>> "It's difficult to rank technical writers along with Engineers,
>> because people who go into tech writing and QA are usually people
>> who tried to be Engineers and failed.
>
> Your boss is correct in some regards. Many writers are writers
> because they aspire no further. Half the writers I meet are writers
> only because they want to pay the bills and cannot get a job doing
> anything else. This might not be the case for yourself, but it is for
> a lot of writers out there (in my experience).

I really have to take issue with this.

Before I get into details, I should caveat the following with the
facts that a) I am one of the more technical folks, and b) in fact I also
left tech writing for consulting (doing Perl/Java/RDBMS dev for web
sites).

Also, in most of the following, I base my comments on experience
in the software development world. I will caveat that caveat with the
fact that most of what I've heard from other writers backs up my
statements, and in any event I have heard statistics that place the
distribution of technical writing work at something like 50% in the
computer field.

I know the common stereotype of a technical writer is that of a
failed engineer or programmer who becomes a writer because they can't
hack the serious work.

I also know why this arises - because of the common management
misfocus on hiring knowledge domain experts to write books instead of
hiring writers. This happens because it's easier to figure out
whether somebody knows about or is experienced in a knowledge domain
than to figure out if they're a good technical writer. The fact that
writing ability has a lot more to do with whether the book is readable
or not than knowledge of the topic kind of slips by management*.

This leads to subsequent confusion between cause and effect, and
hence we get the stereotype.

(You can *get* knowledge, but it's pretty hard to develop writing
ability within the scope of such a project).

In my experience, I know far more people who, like myself, are
failed technical writers turned programmer (or engineer or whatever)
than vice versa. This happens quite simply because a) writing is a
lot more difficult in everyday terms than being a programmer, and b)
writing doesn't pay nearly as much as programming, in either cash or
respect.

To clarify "writing is a lot more difficult", I'm talking about
sheer day-to-day obstacles to writing. The ratio of writers to
projects is almost always the opposite of the ratio of engineers to
projects. On a software dev project you'll usually see a team of
engineers and one writer - who also has responsibilities to other
projects. Writers are also largely self-managing; they have to be,
because they so seldom work in a team-writing situation*.

(* Team-writing can be a *lot* of fun, when it works right).

Writers also have to contend with the fundamental contradiction
that they always have to do the most to adapt to changes, while having
the least influence over whether that change will happen or not. If
things come to a showdown, regardless of who's right, who do you think
will lose - the writer or the engineer who gets paid twice as much?

Writers are responsible for a large amount of the whole
"interface" of the product - where interface is defined as the part of
the product that the user directly interacts with - yet they have the
most constraints in developing it. They are required, by the role
most employers force them into, to be reactive. To react to change,
not to initiate it.

In the ideal world, the writer works with a stable product that
is undergoing final Q&A. In the real world writers work with
barely-usable or unusable products 99% of the time, and typically have
more severe deadlines than engineers, due to production lead time
requirements. Management wants that product shipped out the door as
soon as possible, and although they'll scream bloody murder if the
docs aren't done, they don't consider the docs as part of the "as soon
as possible" equation*.

It's no wonder so many people get fed up with it and leave for
more lucrative jobs.

(* No doubt in part this goes back to both the ratio and the relative
pay scale; when the software is functional and management perceives
the holdup as being a lone, lowly-paid tech writer and not a whole
team of highly-paid engineers...)


> Now, some writers actually break out of this mold and become
> technology experts as well as good writers. For example, in my line
> of work a technical writer with Oracle experience is like a brick of
> gold. They can command high salaries and great respect. However,
> there are so few writers with this knowledge, that most of the
> writers I interview I turn away.

I'm curious as to what line of work that is. One thing I've
considered in the past year or so is going back to doing tech writing
because of the immense satisfaction I get from writing. I find
programming interesting and satisfying, but not in quite the same way
as writing.

My first tech writing job was developing system admin guides for
a particular flavor of RDBMS on Unix and VMS systems. What's "Oracle
experience"? Experience developing for Oracle? What's enough
knowledge to qualify? How high is your idea of "high salaries"?

> > Also, Engineers can keep learning and advancing
> > in their field, but technical writers have no
> > where to go or new things to learn."
>
> This is essentially true. Tech writing has not changed much in the
> past 10 years. Get mad an curse my name, but apart from a few new
> tools, on-line help, and some interactive medias - by and large
> technical writing is pretty much the same as it was 10 years ago.

I don't know as I'd agree that tech writing hasn't, or doesn't
change. In fact, I do believe that by reviewing the computer books
published over the last forty years we'd probably notice some very
interesting trends. However, I haven't done such a review, I don't
know of anyone who has, and I'm not going to waste our time by making
uneducated guesses.

> Moreover, what has absolutely remained the same over the past decade
> is that the majority of writers obsess over tools and techniques while
> never focusing on the technologies they are documenting.

I'd say that you're once again confusing cause and effect.
Writers expend energy on tools because management obsesses over
tools. Once again, "knows how to use tool XYZZY" is much easier to
define (and theoretically check) than writing ability. Like it or not,
writers have to contend with this*.

(* Note that programmers run into a similar issue; a good programmer's
ability doesn't depend on familiarity with a particular development
environment, or in the case of really good programmers (I don't
count myself as one) even with a particular programming language.)

And *techniques*? If you're talking about worrying about whether
to write it as "online" or "on-line" or whether to put two spaces or
one after a period, I agree that it's not worth my energy to worry
about it. On the other hand, debating on somewhat more subtle and
complex issues of phrasing or terminology can be a pleasant - and even
somewhat useful, if not critical - way for writers to "shoot the
breeze".

Programmers spend plenty of time in debates over particular
idiomatic ways to express something in code, or on issues of code
formatting (indentation being one good example). The decision in
itself usually isn't that important, but the discussion of the
decision is usually a good way to stretch your mental muscles and can
be educational in itself, whether for writing or programming.

If "techniques" refers to the larger scale techniques of writing
large documents, techniques for developing information, techniques for
managing (usually self-managing) writing projects, then this is
certainly time well spent and part of what makes a writer the right
person to hire to write docs.

> In comparison, software design and development has dramatically
> changed in the past 10 years. Entire new languages have risen and
> fallen in the past 10 years. Moreover, the technologies are radically
> different.

I know plenty of hardcore programmers, software engineers and
computer scientists who would argue that nothing substantial has
changed. I'd guess the majority would feel that some things have
changed, even some substantial things, but not enough to say the field
is "radically different", to the extent, as you're implying here, that
Engineers have a herculean task just keeping up with the field, which
justifies them being considered first-class citizens compared to
tech writers as second-class citizens.

I wrote a reply to the remainder but upon reviewing it, I found
both the original comments and my reaction to them to be largely
inflammatory and chose to save time and energy in the long run by
dropping them from the thread.

Steven J. Owens
puff -at- netcom -dot- com

From ??? -at- ??? Sun Jan 00 00:00:00 0000=




Previous by Author: Re: No one reads the manuals
Next by Author: Technical writing position--Broomfield, CO
Previous by Thread: Re: Value of technical writers - Sorry, boss is (mostly) right
Next by Thread: Re: Value of technical writers - Sorry, boss is (mostly) right


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads