Re: TWs and their work tools!

[<puff -at- guild -dot- net>]

> Although it's helping you to do your job using your own equipment
> and software, I think you may be shooting yourself in the foot in
> the long run. Why should they bother to upgrade you when you're
> doing it for them?

     I've had serious thoughts, in past contracting jobs, about doing
something similar, or about building a "hardware budget" (literally)
into the contract.  In reality, nobody wants to hear about that, just
like they don't want to see an itemized rate sheet with extra charges
for:

     - commute times
     - parking hassles 
     - cubicles
     - suit & tie cleaning
     - suit & tie pain and suffering
     - corporate bureacracy
     - boring monotonous work

     They'd much rather you just fold all of that into the rate you
give them... which I do!  Of course, caveat that with the fact that I
moved into programming (kept getting better offers) a couple years
back.  Someday I want to get back to writing.

> What I would do in this frustrating situation is to, as much as
> possible, make friends with IT. How well this works depends entirely
> on the amount of interaction and contact you have with them. Some
> places, I couldn't have told you where IT was located, much less who
> the people were, others I knew them very well.

     The IT field has a long and honored history of minor bribery and
currying of favor.  Two things to understand about the IT guys:

     First, they and tech writers have more in common than you think.
Just like the tech writers they're seen as overhead, so they're always
understaffed and overworked.  Just like the techwriters, IT planning
and preparation always last on the list of priorities - until you need
something they haven't had time to prepare for, and then you need it
NOW DAMMIT.

     Second, like a garage mechanic, they're used to most people just
coming to them with a "make the problem go away" attitude.  Most
people don't want to take the time to understand what the problem is
and what the remedy is.  Hence, they'll tend to be skeptical of any
problem you bring to them.  Demonstrate that you're on the ball,
willing to do your own homework, and maximizing effective use of their
time (i.e. take notes and try to understand what they tell you) and
they'll more likely be interested in investing time in you - and that
means they'll be better disposed to you when the opportunity comes up
to steer some good hardware your way.
 
> Plug away at your job, documenting every time you lose time and data
> due to crashes and lost files. You have deadlines? Explain to your
> manager that, given the equipment, you can't promise to meet it
> because....and produce the list you're keeping of time and data lost
> when the system crashes, especially if it does this frequently.

     The trick is to make the cost of these problems visible to them.
If you have any standard steps or situations that recur frequently, do
some basic analysis and record-keeping, particularly if it's things
like doing a file format conversion or anything where you point and
click and fire it off and don't touch it until it's done.  

     For tasks where it's just the excruciating user interface
slowness, try timing a task on a neighbor's more powerful PC and on
your PC.  Carry out the exact same task three times on each, for
comparison (alternate between PCs to level out the amount of practice
you're getting). Put it in a nice official-looking format (but not
*too* official, don't want it to look like you were wasting all your
time on that :-).

     Two anecdotes from my former life as a writer come to mind:

     In one, I was given a horrendously inadequate, buggy, incomplete
product to produce docs for.  My employer had acquired it from another
company.  Going through the various generations of docs for it, I
determined it had gone through about five different acquisitions, each
accompanied by a name change and rewriting the docs in a "more
professional" style while removing any useful content.  In one case
there was an obvious overly broad global search&replace which screwed
up a lot of examples (because the examples used the command-line
product file name, which happened to be similar to the product name).

     My boss had just the week before given me a pep talk about
project management and keeping track of where you put your time.
Halfway through the first day I started a micro-managed log of what I
was doing, how long it was taking, and what was happening, backdating
it to include that day.

     Two weeks later my boss called me into a meeting with the CEO,
Marketing VP and Development VP.  She asked me to tell them how it was
going with the new product and would it be ready to be bundled with
the imminent product release.  I pulled out the time log (five or six
pages of densely typed entries) and said that in the 96 hours since
I'd been handed the project, over half of that time had been spent
literally sitting in front of a system console, trying to get the damn
thing installed successfully, which I had yet to accomplish.

     They decided to postpone releasing the product.


     Second example, same company, they had the six tech writers using
FrameMaker, served off an entirely inadequate SGI Irix workstation
(which had the additional burden of serving fonts to several of the
engineers who'd decided they'd get snappier performance that
way... boy did some heads roll when I figured out what was going on!).
Frame has (or had, I hope it doesn't still have it) a license system
which uses a daemon process that checks out licenses to user
FrameMaker processes and generally makes sure you're not running more
copies of FrameMaker than you paid for.

     Problem was, an "unreproducible bug" (according to the Frame on
SGI release notes) was causing our FrameMaker processes to lock up for
ten minutes, then crash.  Then you had to wait 30 minutes for the
license daemon to time out the license that had been checked out to
you, so you could restart Frame (and hope your files were properly
checkpointed - at this time I developed the mantra "save early, save
often").

     Even worse, half the time they took the license daemon down with
them, and surprise, the other five writers lost THEIR processes TOO.

     We got a notebook and started keeping a log of the crashes, date
& time, file, error message, user, how much time was lost, and any
other relevant details.  Eventually we started tarring up core dumps
onto tape files and shipping them off to SGI for analysis, but we were
still stuck on that box and we were still contending with pretty much
daily crashes.

     My boss called me into a meeting with upper management to discuss
the problem and the costs involved.  I brought an inch thick stack of
crash reports from the preceding, oh, maybe six months or more and
thunked it down in the middle of the conference table, with a one-page
statistical summary on top.

     We moved the writing team to the engineering departments brand
spanking new Solaris server.

 
Steven J. Owens
puff -at- guild -dot- net

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17)
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 
Conference East, June 4-5, Baltimore/Washington D.C. area.
http://www.pdfconference.com or toll-free 877/278-2131. 

---
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.