RE: Searching through Code [WAS: In Search of a Class]

["Giordano, Connie" <Connie -dot- Giordano -at- FMR -dot- COM>]

Paul,

Absolutely right!  Which is why functional, design, and technical
specifications are so important.  And the ability to communicate with the
developers who write the code.  I have never needed to dig into code to find
out why something works the way it does.  If I can't figure it out from the
UI or the specs, there's a problem.  And if you don't have specs, you have
an even bigger problem.

Connie.

-----Original Message-----
From: Paul Hanson 

[snip]
	She told me, and I remember it well, "Tech writers should stay
out of the code. You wouldn't like it if they were in your documents."
Being new to working with her and to tech writing in general, I didn't
have the nerve to say I was in Display mode.
	Now, it's 5+ years later, and without starting a war of words, I
tend to agree. At the company I work at now, going into the code is
normal for people in my department, but I still remember at my interview
voicing my skeptiscism (sp) that I would ever get into the code. So far,
and after 1.5 years, code hunting has not presented itself to me.

Gay Reed wrote:
	<snip>
		I have often found it frustrating to happen upon a
disabled field or control that clearly held the key to my successful
completion of the task at hand only to find no clues as to the secret
handshake required to enable it. In my own 	documentation efforts, I
examine the code to learn the conditions under which particular controls
are enabled or disabled. 	This allows me to tell the user WHY and
WHEN a control is available or unavailable, circumventing unnecessary
frustration 	where possible.
		<snip>