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.
Subject:RE: "If the docs are too good..." From:"Bill Swallow" <wswallow -at- nycap -dot- rr -dot- com> To:"'Sean Wheller'" <seanwhe -at- yahoo -dot- com>, "'TECHWR-L'" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sun, 8 Feb 2004 14:40:40 -0500
::: AFAIK the developers rarely do produce better programs
::: as the additional cost and time required for usability
::: is often prohibitive.
Only when poorly planned for.
::: Your comment also highlights a general problem. That
::: most developers do not see the tech docs and the
::: author team as an integral part of product
::: development.
Not "most"... "YOUR"...
::: Not to generalize, but many developer teams are stuck
::: in an ivory tower. The result is often poor team work
::: across the project, with the lack of cohesion
::: impacting on areas such as documentation, testing and
::: QA.
But that's where WE, the professional communicators, come into the equation.
::: Time and again, I have found myself having to take a
::: slow approach to changing this mindset and I see this
::: experience resonating in some discussions on this
::: list.
You don't work to change an existing mindset. You can't. Rather, you
initiate and influence another. Those with no ties to one particular way of
doing things will likely follow along, provided your proposed way
illustrates benefits. Get the right people on board and anything's possible.
::: It's almost as if there is a glass ceiling that must
::: be broken if the product is to reach higher-levels.
The glass ceiling may or may not exist, but it's a choice to avoid contact
with it rather than shatter it.
Bill Swallow
wswallow "at" nycap "dot" rr "dot" com