Re: interviewing tips

[Chris Tonjes <ctonjes -at- MINDSPRING -dot- COM>]

This is how a good technical writer gets information. It's also how a good
technical writer becomes an integral part of a development team.

For those timid souls having trouble getting information from big, bad,
developers: print John's message and memorize it. Forget about food and
bogus confrontations (questioning developers on their design decisions as a
way chatting them up). John's way is the way grownups work together.
>
>
>-----Original Message-----
>From: John Posada <john -at- tdandw -dot- com>
>To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
>Date: Thursday, November 27, 1997 11:10 AM
>Subject: Re: interviewing tips
>
>
>>Guys...relating to this interview thread, which couldn't be timed better
>>with what I have going on at my job.
>>
>>An interesting situation happened this Wed evening as I was walking out
>>of the door (I had my coat on, in fact).
>>
>>I had mentoioned to one of the department managers a couple of days ago
>>that I noticed in the programmer's weekly department status report that
>>a particular program had been upgraded to a new release and deployed on
>>the servers.  Understand that I came on about a month ago, there was NO
>>formal document process, and I've been trying to track down all of the
>>documentation floating around, and I haven't even scratched the surface
>>yet.
>>
>>Anyway, the manager told me that this particular program belong to
>>"Matt".
>>
>>Now, Matt is as geeky as they come.  If I spent 10 hours per day juts
>>writing code for UNIX servers, I'd be pretty geeky too.
>>
>>Anyway, as I'm passing his cube, I mention to him that I'd like to get
>>10 minutes of his time next week to discuss the changed to the program
>>so I can update my document (only about 7 pages).
>>
>>His response was that "he didn't see any purpose to having documentation
>>for this program (or any internal program was the implication) because
>>it changes so often that any information about the program is just sent
>>around to all of the developers by email."  (Oh, boy...this one is going
>>to be fun)
>>
>>My response, which resulted in about 30 minutes of discussion why
>>documentation was necessary BECAUSE of the changes and some alternatives
>>that could accomplish what I need without work on his end...like simply
>>add me to the email distribution list that is used to notify his peers
>>of these changes.
>>
>>However, some time in the middle of the conversation, he mentioned that
>>he'd written a tool to solve a particular problem in using the program
>>and that he hadn't deployed it yet. I didn't say anything about it at
>>that point, but mentally filed it away.
>>
>>Later in the conversation, I brought up the subject of his utility and
>>why it hadn't been deployed. His response was that he hadn't made it
>>available yet because he had to write the instructions on how to use it
>>and he hadn't done that yet.
>>
>>Who says Christmas doesn't come in November.
>>
>>To make a long story short, he called up from his terminal and emailed
>>to me a change history document on the program, I have an appointment
>>next week, and I'm going to help him write his instruction on using his
>>utility for use by all of the other programmers in the company.
>>
>>The moral of the story.  Keep your ears open for anything that may be
>>discussed during a conversation that you can use to leverage what you
>>want by doing something for the developer that wasn't in the original
>>job scope.
>>
>>
>>
>>M. Dannenberg wrote:
>>>
>>> In an episode of Northern Exposure, Fleischmann says: "If you want to
>>> catch fish, you have to think like a fish." If you want to catch geeks
>>> you have to think like a geek. A large part of any geek training
>>> consists of stuff like "this is algorithm A, this is algorithm B.
>>> Compare them and say which one's better". The answer is usually "it
>>> depends on your application". Another all-time favoured is comparing
>>> programming languages, like "what are the performance issues when
>>> comparing C to C++", etc.
>>>
>>> The more geeky your questions are, the more inclined the geeks will be
>>> to answer them. If you ask "what's a method?" the geek will groan and
>>
>>
>>John Posada, Technical Writer (and proud of the title)
>>The world's premier Internet fax service company: The FaxSav Global
>>Network
>>-work http://www.faxsav.com     -personal http://www.tdandw.com
>>-work mailto:posada -at- faxsav -dot- com  -personal mailto:john -at- tdandw -dot- com
>>-work phone: 908-906-2000 X2296 -home phone: 732-291-7811
>>My opinions are mine, and neither you nor my company can take credit for
>>them.
>>
>>HEY! Are you coming to the NJ TechWriter lunch?  So far, about 10 of us
>>are.
>>Ask me about it.
>>
>> http://www.documentation.com/, or http://www.dejanews.com/
>>
>>
>

	http://www.documentation.com/, or http://www.dejanews.com/