TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
RE: Do'ers and Doubters (was observation about engineers)
Subject:RE: Do'ers and Doubters (was observation about engineers) From:KMcLauchlan -at- chrysalis-its -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 15 Oct 2001 09:56:24 -0400
[...]
> As a "bash it with a hammer until it obeys" type of person
> myself, I can
> appreciate the more thoughtful methods of my engineering
> pals. They can
> usually reason through problems with greater precision and handle more
> fundamentally complex problems (like programming). But, I
> also know that
> eventually, you have to stop planning, thinking, and
> pondering and start
> whacking things (or people) with hammers if you want to ever
> get anything
> done.
>
> I would also appreciate only reactionary, illogical and irate
> responses to
> this post - so that I can look like a genius. :-)
Well hell! Always glad to oblige.
The low file cabinet in my cube is at the entrance.
I keep a few of those bent-metal puzzle thingies there.
I tell people that there's a reason I don't have a guest
chair in my cube, and that the angular pointy objects
are useful to keep opportunistic bums from using the
top of the cabinet as a seat. Actually, they are an
amusement (one could say attractive nuisance... :-)
and conversation starter, and have started a trend of
other folks bringing in wood-block, rope, etc. puzzles.
We've noticed a divide similar to what Andrew mentions,
except that this tech writer, SOME of the Customer Support
crew most of sales and at least half the engineers seem
to be "bash until" types.
But here's the scary part. A couple of engineers and one
sales type immediately took an analytical approach (complete
with tables and sketches) and solved several puzzles in a
fraction of the time that we "bash until" types took.
One puzzle ("Ages 5 to 95", it sez on the box) is a big
cardboard triangle, cut into nine smaller triangles. The
big triangle has a bunch of cartoon lizards printed on it,
and the object is to lay out the pieces into a big triangle
such that all appropriate lizard-bits match up. That one gave
the most dramatic demonstration of the analytic approach
defeating the "bash until" approach. Dammit.
In terms of work, at our small company, the engineers all
receive the e-mail that comes to our Customer Support
mailbox. Only Customer Support are allowed to reply to
customers. For the rest of us, it's info-only and in-house
discussion.
I notice that the official Customer Support folks do some
analysis, but usually make gestalt and recipe responses.
Sometimes it works, but often the customer replies that
s/he has already tried that (whatever that is) or that it
doesn't address the problem. The engineers often take
longer to reply, but come up with an analysis and suggested
solution that works. In other words, "bash until" seems
to work best with situations we've met before, or situations
that are analogs of ones we've met.
But, there's a third category of problem. Our stuff needs to
work in conjunction with third-party software and systems.
A goodly number of incoming problems are resolved only by
a combination of Customer Support and development engineers,
because the development engineers don't have the exposure
to customer/third-party systems that the support people do.
The "bash until" and the deep analytical approaches must
combine to solve many of the problems because the information,
experience, and capabilities of the individual groups are
insufficient.
When I write a document, I need both approaches not least
because my audience encompasses both kinds of people.
So, not only do I include the step-by-step, how to get there
from here, stuff in my docs, I also like to include some
of the whys and wherefores, for the people who prefer to
understand before acting... as opposed to those who jump
in with both feet, and then try to figure out later what
went wrong. :-)
So, I'm neither supporting nor refuting, here. I'm just
tossing in some additional mud and stirring a bit.
Have fun, y'all.
/kevin
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Announcing new options for IPCC 01, October 24-27 in Santa Fe,
New Mexico: attend the entire event or select a single day.
For details and online registration, visit http://ieeepcs.org/2001
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.