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: Interviewing/getting info From:RoseCrowe <ncrowe -at- PRIMENET -dot- COM> Date:Wed, 23 Aug 1995 11:25:16 -0700
On Wed, 23 Aug 1995, Marilynne Smith wrote:
> >> Do you at least get a feature list from the developers?
> The developers should be working from something that states the goal of the
> software and its hoped-for features. Now days most companies design the
> software first and have a clear idea what their goals are *before* they
> begin to code it. If the developer knows what he or she is designing to,
> you should be able to find out as well.
Where is that, Marilynne? California? <gr>
Seriously, here in AZ, we run into plenty of companies who still code the
old, bad way. Feet first into coding, no upfront design. Not only do
they not create any type of design documents, they don't seem to hold any
type of design *meetings* that a writer can go to.
The only advice I can give to other writers trapped in similar situations
is to push for proper designing methodology within your company.
Companies that design this way have serious problems that affect the
development of the success of the code, as well as documentation
problems. The Tech Writing Team can become part of the solution.
> As for not sharing . . . you need to develop a better relationship with them
> than just eavesdropping. You should be part of the team. Hopefully "one of
> the guys". <said tongue in cheek>
So if you do work for one of the above companies, you can help solve a
company-side problem by advocating for design meetings and design
documents. You can help the documentation department by making writers
part of the solution form day one. The only problem is being seen as the
bad guys by those who don't want change.
These people will either 1) change and learn to like it, 2) resist change
and end up leaving the company, or 3) give in to an onslaught composed of
bribes, the force of your winning personalities, and your longetivity.
Rosie (NorthCrowe)
ncrowe -at- primenet -dot- com
rwilc -at- fast -dot- dot -dot- state -dot- az -dot- us
*******
Neither a lofty degree of intelligence nor imagination nor both together
go to the making of genius. Love, love, love, that is the soul of genius.
- Mozart