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.
It seems to me that everyone is going 'round and
'round on this topic; when you boil it down, why can't
we simply acknowledge that everyone has an individual
approach to work of any kind?
It is true that some programmers I know become
immersed in the code to a point that any interruption
can throw them completely off track, while others seem
to be able to work in the midst of absolute chaos with
no problem.
In my experience, the best way has usually meant
sending a simple email asking for some time, and
suggesting two possibilities. The result is generally
a third time--but normally it's no great problem.
Of course, in composing the email I generally attempt
to give a brief, logical, and clear exposition of the
points I want to discuss. That way, the programmer
often has examples ready at hand when we get
together--and sometimes can send instructions or
explanations in writing via email and thus obviate the
need to meet in the first place.
When this is leavened by an understanding of the
personalities involved, generally there's no great
problem in devising a workable schedule. For example,
one programmer might be a "slow starter" who putters
around and doesn't mind interruptions for the first
hour or so in the office.
As for those programmers who won't give time to tech
writers and QA people "...until the code is almost
done"...this is the attitude that creates late and
half-baked applications, in my experience. Look at the
results from iterative programming with its reliance
upon constant testing from the first weeks of a
project for an eye toward releasing code that is free
from show-stopping bugs!
For anyone to say "I work in this fashion, and thus
everyone with any job must obviously work in the same
fashion" we betray an insensitivity to our audience,
IMHO. Why not apply our skills in audience analysis to
our interpersonal relationships within our own job
setting, recognizing that we'll get much farther than
if we simply assume that everyone will conform to our
own preferred method of working?
Regards,
David
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. 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.
