Re: Background

[Jane S Torpie <handson!boston -dot- handson -dot- com!janet -at- UUNET -dot- UU -dot- NET>]

Don Sargent asks about hiring Sr. Tech. Writers for to document an OO
software development environment....

Don -
A month ago I left exactly such a position, except that I was a Principal
Writer and then  Member of Technical Staff.  (Just for the record, I left
because I was seeking a career change, pref. to technical marketing.)  I
have a BA from a liberal arts college that is hailed for its humanities but
not its computer curricula.  I can program and am one of the techie-types of
technical writers.

These days, many organizations are moving away from titles such as "writer"
and "engineer" to MTS instead.  (Pam Tatge of TI, are you out there?)  IMHO,
this is an accurate indication that all team members will have to learn to
meet existing and new needs by working in ways they might not have worked
before.  Especially if you're applying workflow* theory to your
organization, you'll need someone who can learn and be flexible.

I read somewhere recently (sorry, can't direct you to a source) that some
people think the learning curve for OO is the same as or possibly less than
that for traditional procedural programming languages, esp. if the person
hasn't been a programmer before.  This made me challenge my ideas about how
difficult the material really was,

In my experience, having a background totally devoid of OO didn't hurt me a
bit and was even a benefit to my employer because I could more nearly mirror
the new OO customer.  Our company had another senior writer in the same
situation.  (An aside to interested lurkers:  Most of the market consists of
organizations that are either newly adopting this technology or have
developers who are learning it.)  I asked lots of questions, played with my
own examples, and made friends with the application consultants.  A VP in my
company even suggested that I become an application development consultant
because my mind hadn't been moulded by the patterns of  procedural
languages.

I'd suggest looking for someone who can learn and who is willing to do so.
 I'm not sure how much help knowledge of Pascal or C is, except that it
demonstrates programming ability in a general way. And it's not necessary to
use C++ in an object-oriented fashion; it's perfectly possible to do a lot
of work procedurally.  (Consider DLLs.)  Yes, the learning curve is big, but
every company in that part of the industry is trying to surmount that curve.
 How about telling your candidates that you will expect them to come up to
speed in X, Y, and Z by some particular time and suggesting a way to do it?
 Could be a college course after work with tuition reimbursement.  Could be
the company training course followed by work with the support people or the
application consultants.  Could be work on an in-house project  with someone
else in the company who knows the product. Their willingness should also
tell you something about their attitude.  And your willingness to train will
make you a much more attractive employer, so you stand to get better
candidates in the long run.

The technology is too new to expect people to have all the ingredients.
 (Because of this, those who do will probably be in a salary range that's
above the budget, or they'll work contract to get the money.)  So get
someone who can write and groom 'em yourself.

 --------------------------
*Briefly, the idea of workflow means that instead of speeding up any given
process by automating (doing the same things faster), you analyze and re-do
the process so it's more efficient.  Sometimes steps are added, often steps
are dropped, and usually some steps are combined or reorganized entirely.

Jane S. Torpie
Course Development Consultant
janet -at- handson -dot- com