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.
Subject:RE: How to fend off a tech writer From:Price Lisa - IL <PRICEL -at- tusc -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 9 May 2002 13:14:51 -0500
Nope, not true. :) I've gotten the same responses, usually at shops where
I'm a) new to the organization and an unknown, b) the only writer, or c)
both.
Can't add anything to the list Mike already posted. And Matt's suggestions
are worth trying. There are, however, some shops that simply don't know
what to do with all the requests for information they're receiving, or don't
value documentation (or contractors) enough to take the time to answer
questions.
LisaP
-----Original Message-----
Nope. It's just you.
Here's some free advice on how to deal with developers so that you never get
this kind of request from the development department again.
1) Beat them at their own game. Literally. Learn how to play foosball or
Unreal Tournament and then smack 'em down. Gets you some respect, but better
yet, gets you in a position to be around when important decisions are
sometimes made about the product.
2) Don't just go to them with problems. Stop by and say hi sometimes. Or
shoot them an email about something you read on slashdot.org. This way, they
don't see you coming and start running the other way.
3) Get access to the source code and do your own check-ins for docs and
samples. Learn how the source code repository application works and become a
go-to guy for people.
4) Read the code first. You want to ask them a question they haven't asked
themselves, not a stupid question that a typical user might have.
5) Find bugs and report them. Developers have a soft spot for QA folks
sometimes, and if you show them that you are just as capable, it adds a few
inches.
3. The Obstacle: "Put all your questions in writing..."
4. Trial and Error: "Just do the best you can, then we'll review
the document..."
5. What else???
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Buy RoboHelp Office in May and you'll save $100 with our mail-in rebate.
Or switch from Doc-to-Help or ForeHelp to RoboHelp Office for only $499.
Get the help authoring tool PC magazine recently awarded a perfect score!
Go to http://www.ehelp.com/techwr
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
---
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.
