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.
The problem is one of information and knowledge. At some point, practice
becomes implicit. All of us can do many things that we cannot explain.
Programmers and writers both sublimate their professional practice.
In my own career, I've never had to explain why I changed something, and
I've never had an engineer come back and insist on their own language. A lot
of the writers I work with here do get that from their source engineers. My
improvements where on a scale of 80%, and the meaning was not changed. The
engineers were satisfied. They used the finished documents as templates for
their next effort. You can debate the rules with engineers for this tiny
change, and that tiny change, but ultimately, they don't care about the
rules and can order you to put their stuff back unchanged. What good are the
rules then. Either the change is obvious or it won't matter to the source
engineers around here. And, everyone can beef about it.
I once had a programmer writing a requirements manual who took his redlines
and learned to produce text that didn't need to be changed. He learned it on
his own without any explanations from me, or conflict over changes. He has
been the only one interested in improving his writing.
Where I work now, I am expected to take paragraphs that span pages, and
sentences devoid of capitalization and make them readable. I am cheaper than
a programmer. That's why I'm here. You might work with people that accept
instruction and consider source quality an issue. I don't.
Not hiring a writer, because they cannot explain why they made a change is a
mistake when there is no expectation that they would ever explain their
changes. Writers can be expected to not make a huge number of mistakes, and
they can be expected to meet their deadlines. I don't expect them to explain
their mistakes or have theoretical arguments with editors. I do expect them
to revisit the rules when an editor redlines their work, and not make that
mistake again.
Hiring an editor is a different matter. They must be able to explain the
rules.
Perfection is the enemy of good. Good is good enough.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by DigiPub Solutions Corp, producers of PDF 2001 Conference East,
June 4-6, Baltimore, MD. Now covering Acrobat 5. Early registration deadline
April 27. http://www.pdfconference.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.
