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: Thoughts on working WITH developers... From:"Wing, Michael J" <mjwing -at- INGR -dot- COM> Date:Thu, 25 Mar 1999 13:00:34 -0600
As a supplement or alternatives (however viewed) to Eric's list, I approach
Developers as follows:
-> I research the subject matter as much as practical before talking to
them. I even write fiction to fill in the blanks. That is because
Engineers are much better at correcting what is wrong than staring at a
blank notepad and being told to list everything there is to know. Believe
me, they hate the blank page. They will also forget half of what they need
to tell you. Also, in my experience, they hate the 'fill in the
Writer-prepared template'. Every rookie writer comes up with this approach.
Many Engineers hate to fill in prepared templates. It's like homework.
-> Instead of the journalist or interviewer approach, I use a lawyer-like
approach. I script my questions focusing on some specific questions. I
compare the answers to what I thought they might be and mildly "cross
examine" them on the discrepancies. Also, I plan on only talking to them
for 10 to 15 minutes. I tell them this when I ask to speak with them.
However, I goad them into extending the interview through some other
-> A technique I often use is the Trojan horse. In this approach I come
with one or two questions that are easy to answer. However, I slip in 10 or
more "what if" situations and get them elaborating on how they have foreseen
this and that and how the product handles it. Because I document automation
programming code used in customizing our products, I hit them where they
live. If I approach them with a piece of my code that doesn't work, they'll
drop everything they are doing to see why. As they test my code, I ask them
everything about every method, argument, property, and maybe even ancestry.
-> Another technique is the wrong conclusion. I ask the Engineer to
confirm my understanding of the product (or function thereof). As I start
spouting fiction they can't resist correcting me (It's like resisting the
shave-and-a-haircut knuckle rap). And they do reply, " WRONG! NOPE!
You're way off!" If you have thick enough skin to stick around and hear the
answers, they will tell you in no uncertain terms what is right and wrong.
> -----Original Message-----
> From: Eric J. Ray [SMTP:ejray -at- RAYCOMM -dot- COM]
> Sent: Thursday, March 25, 1999 12:39 PM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Thoughts on working WITH developers...