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.
george -dot- m -dot- hook -at- accenture -dot- com wrote:
>
>
>
> First, can anybody out there tell me what this means: "Previous experience
> as a technical writer supporting development and user environments in all
> aspects of the development lifecycle, including production
> turnover/rollout."
It means they don't want someone who comes in with a big chip on his or
her shoulder that reads, "I only write technical documentation; don't
ask me to write a user manual"; and they don't one someone simpering, "I
know all about usability studies and can write the manuals, but I don't
know anything about technology." And when they say "development
lifecycle," they expect the candidate to be able to walk over to a white
board and sketch out a typical development lifecycle.
>
> Second, can someone clue me in as to what a COBOL/DB2 environment is?
> Again, another job description mystery.
IBM mainframe environment. The programming language in which the system
is written and maintained is COBOL (COmmon Business-Oriented Language,
developed in the late 1950s or early 1960s, IIRC, and still in use for
large business transaction processing systems). The database is
maintained in DB2. Depending on the company, you may never even see a PC
there. Instead, you--and the ultimate users of the system--may interact
with the system through a character terminal. Or they may use Windows PC
clients. In the former case, you might find yourself using some rather
awkward documentation tools. A style manual will be the least of your
worries.
>
> And finally, what are you doing about style books these days? I'll bet
> it's the Microsoft Manual of Style for Technical Publications for most of
> you, but how do you introduce it to an engagement? Do you tell a client
> that this is the style book I use, and you should too? I mean, I have been
> fighting this losing battle to convince editors that the Chicago Manual of
> Style and the AP Style Book are fine books ... but not when you are dealing
> with writing technical proposals and manuals.
>
MMoSTP, as discussed here recently, is really a specialty resource for
when you need to talk about elements of the Windows user interface and
want to be consistent with other software documentation. It does not
really serve the purpose of a general style manual. We use it for its
specialized purpose. We use AP for news releases (and _only_ for news
releases). We use Chicago for everything else. That said, there are
still a lot of choices when you get down to cases. Therefore, we are
gradually building a company preference sheet that lists our choices
where they differ from the above books or where Chicago offers "editor's
choice."
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
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.
