----- Original Message -----
From: Laurel Fan <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 15, 2000 4:24 PM
Subject: [issues] YAFGA (Yet Another Female Geeks Article)
> On a completely different subject, what is a better, non-adversarial way
> of analyzing a design? The whole "you point out problems and I'll tell
> you why they're not" thing seems to work pretty well for me...
My background is in theatre, where egos *must* be left at the door[*]. I
found that there were two ways to handle criticism that more or less worked:
a) Peer review. We are our own worst critics -- almost always. If enough
people whom you respect agree that a particular thing needs working on, and
if it's done in an environment where it's clear that the goal is improvement
of the *code* (emphatically NOT the person, her character or her karma[**]),
the criticism can usually work without doing damage.
The critical aspect to this approach is to keep focus on the goal -- in
this case, better code. This goal has to be shared by *everyone* at the
table, everyone needs to have a stake in the outcome, and everyone must be
in a position to offer something of value. I wouldn't ask a set designer to
critique an actor, for instance. In short, having a Pointy Haired Manager at
the table is almost always going to be less than productive. Best to do the
critique, then have the project leader bring the results to the PHM. This
will at least keep the Us vs. Them dynamic in its proper place. 8^)
b) Advice from a recognized guru. This is harder to achieve, and just
who that guru is tends to vary from one person's perspective to another. If,
for example, ESR were to, uh... descend into my sphere and offer suggestions
concerning some technology issues piece I'd written, I'd find it very easy
to accept them. If the same thing were to happen to a devout
Stallman-ite[***], the result might be different.
[* Okay, like that's going to happen.... But you know what? It really
does -- if the atmosphere is right, and the trust is implicit.]
[** This is a little more slippery than some might assume, but it works more
or less like this: "We're not here to make you a better programmer, nor to
rate your abilities. If you learn important lessons from this process,
that's gravy. The task at hand is to produce the best code possible. Let's
focus and get the job done." This may sound cold as text, but body language
and tone can make it a very positive statement that will actually draw sighs
of relief from some.]
[*** I'm really not trying to imply a bias here; it just seems to me that
their divergent approaches to Free/Open Source software are exemplary,
that's all. Personally, I like what both of them have to say.]
--
Dan McGarry
http://www.moodindigo.com/
************
[EMAIL PROTECTED] http://www.linuxchix.org
