TechWhirl Sponsors

About TechWhirl

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.

Yep. But too many times people aren't willing to get "hit" to spur
discussion and learn lessons. I am.

<Snipped>

You said:
How does one develop an aptitude for "this stuff" without gaining some
background? Any experience/knowledge gained in programming creates a
background and thus increases aptitude.

You have confused experience with aptitude. Noah W. says that aptitude is
a "natural capability to learn." Nothing to do with experience.
Therefore, I don't buy your argument here.

You said:

I thought the issue was Technical Writers adding application/programming
skills to their repertoire, not Engineers trying to be writers. Your
correlation sounds to me like stereotype.

Good point. I ranted myself into a stereotype. Still, I think the
communication theory training I had in J-school will carry me a lot farther
in the world of Tech Comm than the Technical Writing class taught in the
engineering building on most campuses.

>>When authoring reference information, the text book doesn't cover it any
>>more gang. The younger gens (like gen X and below... to which I belong
by
>>the way) don't have the attention span to pour over reams of DBC's (dense
>>blocks of crap) to find out how to sub-class a function.

You said:
Good point put rather crudely.
Thanks!

To take this a little further, We are currently challenging the 1.1.
engineering-based document structure every day. By incorporating newer
techniques like Information Mapping, we are producing documents that are:
* easier by design and verbiage to absorb (and yes, we do measure for
retention every once in a while to prove it)
* quicker to produce
* the "best in field" when compared to other documentation from
competitors on a regular basis

>>Most engineers do not have the education/training to communicate
>>visually, to >design documents for easy scanning, high retention and
>>flatter, less confusing >hierarchies.

Another stereotype
but true I'm afraid. When was the last time you saw a CS student in a
communication theory class... or a document design class? Or for that
matter, in a professional seminar about Usability (although this is
changing a bit.)

>>Bottom line to this rant: While I certainly respect greatly the skill it
>>takes to develop truly portable objects for reuse, I do not think anyone
on
>>the development team I sit with would want me to code high-end CORBA/C++
>>stuff. I am not trained to accomplish this, and my efforts would injure
>>the team's overall performance.

So can attitude
Thanks for the shot at the attitude! I'm not as grumpy as I may come
across in an email. Be ye careful to quickly misjudge attitude.

>>In turn, I don't want to have the documentation we produce lessened by
>>people who are not trained to communicate effectively. It is a team
>>approach, you do what you do best, I'll do what I do best. Together, as

>>team, fulfilling our roles, we will succeed.

How do you promote a team effort with attitudes like:

> "I have seen too many engineers turned tech comms who couldn't
communicate their way out of a wet paper bag",

I am simply reporting my experience from my little slice of the world.
Take it as a stereotype if you wish. To further complicate things, I have
also seen tech comm's who need a little help understanding the basic
functionality of the Windows interface too. Again, be careful to judge
one's attitude by the little slice you get in an email from some dark
corner of the earth.

>" Most engineers do not have the education/training to communicate
visually", and

>"I have found a direct correlation between the skill level and the
inadequacy of their communications "?

Mike said:
Bottom Line: If you don't want to develop any technical skills, just
stick with "writing". This way you don't have to worry about padding
your resume with clutter such as "familiar with C++, Lotus Notes, VB,
etc.". However, go to a job fair and see if the recruiters don't
highlight these skills on the resumes handed to them by Technical
Writers who do have this clutter.

You make an interesting point. One that is debated on the list often. Do
we hire tech writers to document API's because they know C++ or do we hire
them because they have a good high-tech aptitude and excellent
communications skills. I have done both. I am more satisfied consistently
with the candidates from the second category. And oh, by the way.... this
has proven true in the contract placement side of our business too.

On the flipside, in the RoboHelp seminar I teach for technical
communicators, one of the first things I tell them is that WinHelp, HTML,
CGI, these are all programming activities. I then congratulate them on
becoming programmers!!

Part of what frames our debate here is the continual "blurring" between
"programming" and "information development," and by the rapidly declining
skill level necessary to "throw-together" an application (Thanks VB,
PowerBuilder, etc.!).

By the way Mike, all of the things you mentioned are on my resume... plus
training in OO Analysis and Design. :-)

Mike Wing

-------------------------------------------------------
Bill Bledsoe "I had a recent rhinoscopy
Documentation Specialist so I could smell every
Envision Solutions recipe"
bill -at- envision -dot- com Adrian Belew/The Bears
or
intlidocs -at- mo -dot- net
bill doesn't speak for envision, and we don't speak for him either.
we like it that way
-------------------------------------------------------