RANT mode on: Getting my asbestos Underoos out of the drawer

["Mike Starr" <writstar -at- wi -dot- net>]

<RANT>

Andrew's example truly disturbed me. A technical writer who would do that
should be flogged. The primary obligation of a technical writer is to
create usable documentation for the customer. 

-----------------------Original Message-----------------------
Andrew Plato wrote

>I am reminded of a director of engineering from a Bay Area company who had
just
>fired his last tech writer. He called me and saying "whatever you do, don't
>tell me how I need to buy some stupid software package that will take you 6
>months to learn."  I laughed.  Apparently, the previous writers spent
close to
>6 months learning FrameMaker and during that time the only document he
wrote
>was a 100+ page style and policy manual about how documentation would be
>written at his company.

Is a 100+ page style and policy manual a bad thing?? No. But in the grand
scheme of things, it's the sort of thing you develop when you've got time
between doing real work. The real work has to come first. "Meta-work" needs
to be subordinated to the stuff that goes out the door. I had the
Documentation Practice manager of a consulting firm I once worked for tell
me that their expectation was that I would be spending 25% of my time on
meta-work. I told her I was appalled and that I didn't see how the
consulting firm could expect that sort of inefficiency in good concience. I
was shown the door not too long after that and I don't regret it a bit. 

After six months on that project, I was the only one of the three original
full-time technical writing consultants who actually completed a
deliverable when I was given the heave-ho. One of the other two writers was
moved to administrative tasks about two months after we started. So if the
two of us with actual writing responsibilities were devoting 25% of our
time to those meta-work tasks and the third technical writer was devoting
100% of her time to administrative tasks, the client was paying for three
full-time technical writing consultants and only getting one and a half.
That's obscene.

Got one writer?? He/she should know the job well enough to make most of the
policy and style decisions. Got a group of writers?? Get together once a
week or so and thrash 'em out. Maybe even write 'em down, photocopy 'em and
pass 'em around.

The current debate hasn't really touched on what I consider the "real"
objective of the processes and packages and style and policy manuals: to
provide a framework for companies to substitue inexperienced (and
inexpensive) technical writers for experienced and highly skilled technical
writers who don't need to have their hand held every step of the way. Let's
face it folks... there's a shortage of top-notch technical writers out
there and if companies can figure out a way to put freshly minted college
grads in place to do their documentation, they're going to do it. 

I see a similarity to companies that have extensive graphics and DTP
groups. Technical writers in many organizations don't have anything to do
with the graphics incorporated into their documents or the layout and
design of those documents. I've always done it all... writing, graphics,
layout and design, the whole enchilada. To me, having to offload those
responsibilities would be like cutting off an arm. These non-writing tasks
help me put things in perspective. Spending a couple hours developing a
flowchart for a complex process helps me understand and better explain it
to the reader. Rearranging the outline of the document helps me arrive at
the most effective presentation of the material. I don't want to give up
those tasks and "just write".

I've built in my own "efficiencies" into my own working style and I'll put
my productivity and the quality of my documents up against anybody's. Now,
perhaps others might give me quality "dings" and fault me for not following
some of the "conventional wisdoms" in the documents I create but I do so
because of philosophical disagreements about those "conventional wisdoms",
not because I don't know how to apply them. And everywhere I've ever
worked, I've been at least as productive as any other writer in the
organization and in most cases I've been the most productive.

Am I the best technical writer who ever lived?? No way. Am I the most
productive technical writer?? No way. I'm good at what I can do but there
are always ways I can improve. I work at improving every day. I try not to
forget the stupid mistakes I've made.

Want me to work with FrameMaker. Okay. Want me to work with Word?? Okay.
Want me to work with Microsoft Publisher? Okay. Don't care what I use??
Okay, I'll use Word. I can make Word do everything I need my DTP package to
do. Do I have lots of problems with Word?? Nope. I've learned how to use it
so that it doesn't crash and corrupt my documents. I've created very large
user's manuals (>650 pages) with graphics on 80% of the pages, TOC, and
multiple headers/footers with Word. I've created very large PDF documents
(>750 pages) with graphics on half the pages and a dozen
automatically-created hyperlinks on every page with Word. Do I care that
you don't think it's good enough for quality technical documentation?? Fat
chance.

Have I ever had problems with Word? Sure I have. I've also had problems
with FrameMaker. I've also had problems with ForeHelp but it's still my HAT
of choice. 

Hell, I've had PaintShop Pro crash on me, too. Does that mean I don't want
to use it?? Hell, no. It's a great product (and incidentally, I love the
help file). Is it as good as PhotoShop? For my needs, yes; for the needs of
someone doing high-end graphics for four-color process printing, probably
not.

The fact is that there are going to be bugs or crashes associated with any
sophisticated computer program but in most cases, you should be able to
mitigate the shortcomings of your tools by being cautious, saving often and
making backups on a regular basis.

</RANT>

There, I feel better now. I had a few other things on my mind but figured
I'd save something for later. 

Mike 

Mike Starr                        WriteStarr Information Services
Technical Writer - Online Help Developer -  Technical Illustrator
Graphic Designer -   Desktop Publisher   -       MS Office Expert
Telephone (262) 694-0932 - Pager (414) 318-9509 - writstar -at- wi -dot- net




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Take XML and Tech Writing courses online!  Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off!  http://www.online-learning.com/index.html.
---
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.