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.
At 05:47 AM 03/17/2000 -0800, Chris Hamilton wrote:
>If what you write allows a reader to reverse engineer
>all or part of the application, you should think twice
>about writing it...we also have an obligation to our
>company and the people we work for.
You're missing my point. An unscrupulous person could just as easily
manage to give a pirated copy of the software to someone who could use it
to create a system.
The difference between a programmer and a developer is that the developer
does full-cycle development ... meets with senior management to assess the
need, plans and presents viable solutions, codes, tests, and implements a
system to resolve that need. Although programmers may be employed to do
the actual coding, they have nothing to do with planning or anticipating
needs -- and many of the most brilliant programmers I've encountered, who
can code a million times better than any developer, are virtually incapable
of assessing or planning.
However, if you hand a good programmer a reasonably decent user guide,
and/or give him access to a software product, he can usually reverse
engineer it to create his own application. Whereas he wouldn't have been
able to anticipate those needs or options, he is remarkably capable of
replicating a system once he has been exposed to it.
This has nothing to do with proprietary information -- just with the
general flow of any type of application. For this reason, many employers
would not want their user guides indiscriminately circulated -- e.g., if
Company A has had a system developed to improve the way they do business,
they won't want to make it easy for Company B to compete with them.
Although there are many ways for competitors to obtain information/samples,
few employers would want to improve the odds by having them circulated by
former employees.