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.
Technical Writer noted: <<The requirement for "programmer writer" and
"writer programmer" are becoming fairly common--enough so that it is
the only type of contract work I have applied for in the last year or
so.>>
That's sad to hear, because it means that companies are still
foolishly insisting that one person can do the work of two people.
This isn't an expertise issue imho; it's a simple matter of time. This
only makes sense when you don't have enough work to employ a full-time
programmer or a full-time writer. In that situation, having dual
expertise is a very good solution. But when you have a sustained 80
hours worth of work, your programmer-writer ends up either burning
out, or accomplishing only half of both jobs.
<<Basically, it is a big step away from the simplistic definition
(typical in college and university "technical communication" majors)
of technical writers as "user advocates" who are essentially clueless
about the technology they are tasked to document. That is, the rather
unusual argument that technical writers should NOT be subject matter
experts because they are then more able to create documentation for
typical users is losing its allure.>>
I'd be sad, but not surprised, to hear that this is all the
universities are teaching. Sadly, universities are no better than the
real world when it comes to jumping on overly simplistic solutions
rather than embracing complexity. The real situation is far more
nuanced: a technical communicator must understand both the subject and
the audience sufficiently well that they can bridge the gap between
them. When the audience is composed of pure geeks, the communicator
must speak geek fluently and well; when the audience contains few or
no geeks, the communicator must have the common touch and speak the
language of the masses.
The problem with subject matter expertise is that it's easy to lose
the common touch. The reason I've never had any trouble finding
lucrative work as an editor is that the majority of geek authors
(scientists, engineers, programmers, and the like -- and I've worked
with enough hundreds of these authors that I can assert this with some
confidence) lose that ability to remember what it's like to be
ignorant. And that applies both when they're writing for their peers
and when they're writing for non-experts. I tend to believe that the
greatest asset an editor can bring to communication is the ability to
understand both the details of subject and what it is like to not
understand that subject.
<<It is becoming increasingly common to see ads for technical writers
in the finance industry that require Oracle, DB2, or SQL Server
certification in the basic requirements. Similarly, "software
documentation" positions increasingly require programming competence--
typically vendor certifcations such as Sun Certified Java Programmer
(SCJP) or Microsoft Certified Technology Specialist (MCTS). The
certifications are often specific to the job, rather than generic; a
technical writer applying for a position documenting a new Oracle
database installation with an Oracle Certified Professional (OCP)
certification is much more likely to be a prime candidate to fill the
position than another writer with only an MA in English Literature.>>
That's an important point, but only with a large caveat. In the
situations you're describing, the programming expertise is only
relevant when it's necessary to explain the plumbing to the audience
for the documentation. That's true, for example, of software designed
for database designers (e.g., FileMaker) or API programmers. If a
product for a general audience (not for experts or fellow geeks) is so
poorly designed that users need to understand details of the plumbing
to use it, then the product is a design disaster. For example, what
earthly purpose does it serve to explain the details of memory and
stack management in C++ or C# to users of Word? For end-user products,
all that users ever see is the interface, and describing how the
interface works requires no programming expertise whatsoever.
<<Bottom line is the same as for programmers and developers; if you
want to work in a particular field, learn all you can about that
field, including "subject matter expertise.">>
Here I heartily agree. You cannot edit substantively if you don't
understand what the author is saying. Moreover, being able to speak to
the author in their own language is the only way I've discovered to
get them to treat you as an equal or near-equal, at least during the
initial "getting acquainted" stages of the relationship.
--------------------------------------------------------
Geoff Hart (www.geoff-hart.com)
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
--------------------------------------------------------
***Now available*** _Effective onscreen editing_
(http://www.geoff-hart.com/books/eoe/onscreen-book.htm)
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
