Re: Tech Writer Skills

["Martin, Chuck" <chuckm -at- EVOLVESOFTWARE -dot- COM>]

While I agree that tools can be learned, tool mastery--or at least
familiarity--means that companies don't have to spend as much for
training costs or for waiting for a person who has gobs of writing
talent come up to speed with the company's choice of writing tools.

But, especially in the computer hardware and software industries,
"technical writers" often do a lot more than just write. To use my
experience as but one example, at my current position I:

- had to choose a Java-based Help tool
- have to understand Java so I can work with one of our programmers to
implement the chosen tool--and I might actually and up writing some of
the Java code
- read Java written by other programmers to understand their code
comments to see if they are right or complete
- give feedback on the interface design

In past positions I have designed the interface for a utility
application (using Visual Basic), performed testing and interpreted bugs
found (sometimes by understanding what was happening inside the
operating system), entered bugs into database programs, designed the
appearance of Help systems, created and modified screen capture
graphics, wrote macros to make my writing work easier, and much, much
more.

The capability to do these things, or similar things, in addition to
write well (sometimes a rare skill in itself) adds a *lot* of value when
presenting yourself to a prospective employer.

To be fair though, many employers really don't know what they want--or
what they need. Too often clueless HR people (are there any other
types?) throw a lot of buzzwords into job requirements, some of which
come from an engineering staff that does know what a good technical
communicator can do. The counter to that: continued education.

A story: at my last long-term employment (a company that I really
enjoyed in many ways), I was hired as your basic technical writer and
assigned to a couple of projects. Shortly after I started I began going
to the weekly project meetings, which up to the had been basically been
attended by the owner, the project manager, marketing, the programmers
on that project, and the QA manager. The project manager at first
questioned my need to be there, but I insisted that I was part of the
team and needed to know what was going on. As time went on, I would make
contributions in the meeting, not always related to "writing," but also
to usability, market knowledge, and so on. I then started attending
"bugwalks," where the team would review product bugs (and where
sometimes changes were made that I would need to know about), and
sometimes I would be able to contribute to solutions. It was there,
after more than a year there, that I was asked to do the design of a
software product. When I finally left, I was told by the same product
manager who didn't want me in those meetings in the first place that he
was really sorry to see me go and that he really wanted another "me" to
replace me. By showing what I could do, the different skills--besides
good writing--that I brought to the table, I was able to educate them
about the important diversity of skills. They understood, too, that it's
not just about FrameMaker or RoboHELP or Ventura. It's just that many
places, even after all these years, still don't have that understanding,
and that's why they think tools are important.

BTW, I am firm in my belief that technical communication is an
engineering discipline. By advocating that, we may eventually begin to
considered on an equal footing as the code jockeys, both in pay and
prestige. But it's still a long road yet....

> Tony Rocco wrote:
>
> <snip>>recruiters and employers want a laundry list of skills that
have
> nothing to do with the ability to write clear sentences
> and organize information. </snip>
>
> Well said, Tony!  When searching for my first Tech Writing position, I
> was frustrated by many recruiters/employers who were seemingly
> "indifferent" to my writing and editing abilities. Most of the ads and
> requisitions I saw *rarely* mentioned the ability to write
> understandable, logically constructed, and grammatically correct text
> as a requirement.  Usually, I was presented with a laundry list of
> software programs and programming languages.
>
> <snip>Hey, I am a WRITER, not a software engineer, project manager,
> programmer, database administrator, network systems administrator, or
> holy man from the East. It's nice to hear that someone thinks of
writing
> as the main thing a writer should be able to do.</snip>
>
> I agree.  In interviews, I would stress that I had solid writing
skills,
> an eye for detail, and the ability to edit both my own work and the
work
> of others.  I had organized, well-written samples in my portfolio. I
had
> the requisite/non-requisite B.A. in English. Heck, I even had Word,
> WordPerfect, and a basic knowledge of HTML. I was interviewing for
> "junior level" Technical Writing jobs, but was excluded simply because
I
> had never used Interleaf, RoboHelp, Frame, or programmed my PC to
speak
> to me in Sanskrit.
>
> I'm not saying that tools mastery is not important -- I just wish
there
> was more emphasis on the ability to write, learn quickly, and work as
> part of a team than whether you know "X" software tool. I'm happy to
say
> that I finally found an employer who *did* look for writing ability,
and
> so far, I've gotten nothing but positive feedback.  And I've been able
> to learn FrontPage, CorelDraw, and advanced HTML skills on the fly, to
> boot!


--
"You don't look American."
"Everyone looks American, because Americans are from everywhere."

- Doonesbury
Chuck Martin, Technical Writer
Evolve Software                  | Personal
chuckm -at- evolvesoftware -dot- com        | writer -at- best -dot- com
www.evolvesoftware.com           | www.writeforyou.com