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

[Paul Hanson <PHanson -at- Quintrex -dot- com>]

	Funny story about searching through code. When I was really new,
my mentor told me to go talk to Joe Programmer and find out the valid
values for a field. I went to Joe Programmer, he went into the code and,
rather than waiting for me to scribble down what we found, gave me
instructions on how to get into the programmer and what function keys to
use to search for what I needed.
	Well, I did so. Went in under Display mode and found my answers.
	An hour or so later, my mentor came by and asked what I was
doing. I said I was trying to find the values. She saw that I was
actually in the code. She flipped out, ranting about how I could cause a
lot of damage to the program by accidently moving one character or
deleting a letter somewhere. 
	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>