Working with developers

["Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>]

Erik Larsen asks:

*******************
I'm curious how folks on the list tackle the learning/research phase of writing.
What do you find most beneficial:  Interviewing developers, hands-on experience
with a beta product, looking at actual code, design specs, etc.?

<he also mentioned interviewing programmers was not productive for him>
*******************

First, remember you're the guy who scratched "professional communicator" on your
shingle and hung it out; I've always felt that makes the tech writer the party
with greater responsibility for making sure communication takes place.  Mike
Pope's suggestion to hang around with programmers is an excellent one.  Perhaps
I've lead a sheltered existence, but I'm amazed at the formality in the
relationship between others on this list and their programmers.  I've usually
been within eraser-tossing distance of the application developers; never further
than a short walk.  Obviously, you can't abuse easy access, but I've never found
more than simple courtesy and commonsense respect for other people's time to be
necessary.

Remember that programmers have individual learning and communication styles,
just like users.  At one company where I worked, there was one programmer who
would respond to, and act on, a serious discussion, but questions left in his
in-box would stay there until they turned to compost; the other programmer
couldn't seem to remember details five minutes after we talked, but responded
faithfully to anything put in writing. Find the style that works for the
individual and use it.

If possible, get on the design team for new projects.  One of my more
successful efforts was a small system where the team was a single
developer/analyst and me.  I went to all the design conferences with users, we
worked on screen layouts together, and putting the doc together was a snap; I
already had the info I needed, because I'd helped create it.

For maintenance work, find a way to be a user, if possible.  Shortly after I was
hired here, I shipped out to Tea, South Dakota to work as a data-entry clerk for
a detasseler payroll project.  After two weeks of ten-hour days spent in a
small, hot room keying mud-spattered timecards into the system, I *knew* what
the problems were, and nobody had to tell me about data flow.  For the following
year, I produced several new documents that filled holes left by our
conventional documents.

Hope this helps,

Doug
ENGSTROMDD -at- phibred -dot- com