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.
I am not exactly sure what you want, but here is what this
BSEE turned Tech Writer would like to pass on to the Seniors.
PERSONAL HISTORY
I am a BS Electrical Engineering from 1965. We still learned
vacuum tubes then, and there was one course in Switching that
was the path into computer design. And we used our trusty
slide rules. I've kept mine.
I went into the Air Force via ROTC (avoiding Viet Nam), and
wound up working on obsolete equipment, far from any leading
edge. When I got out in '70 a recession was raging, Boeing
was dying, etc. No way could I find design work.
Control Data saw my application, and asked if I would like
technical writing.
Hmm.
I had always gotten straight A's in my English courses, and
ahhhh ... below that in my technical courses. Plus I had done
a pile of installation procedures writing in the Air Force.
I had a family to support.
I took the job.
And I've loved tech writing ever since! There have been times
when I felt limited, and thought seriously about getting back into
the design side. But Laddies and Lassies, when
a) you are making the same bucks as the designer beside you, and
b) you would have to (in good conscience) take a pay cut
to become an entry level engineer, and
c) another baby is due, well,
d) you stay the course.
I have come up through what might have been the most exciting
area of computers: the supers. At Control Data I learned the
basics on terminal and peripheral design by writing maintenance
books, chasing ones and zeros on the checkout floor, and
swapping yarns with engineers and technicians. It helped to
have technical yarns of my own to give.
Then I switched into supercomputers at the CDC Chippewa Lab.
This group under Seymour Cray developed the 6600, and 7600 that were
the top of the line in supercomputers. I myself hand drafted the entire
logic drawing set for the 8600, working from raw Boolean equations.
I also wrote the reference manual that described the cp-by-cp
action of each instruction. That's pretty heavy stuff. I found
bugs and designed the corrections.
I followed Seymour into Cray Research and shipped a manual set
for the Serial 1 CRAY-1. I heartily recommend the young startup
company route for you adventurous souls, because you get to wear
20 hats at once, and you damn well better not screw any one of
them up!
I wrote the hardware side, another writer wrote the software side.
I got the whole system: refrigeration, disks, controllers,
functional units (arithmetic and logicals), CPU, memory, I/O;
you name it, I wrote on it.
An electrical engineer would only work on one area, and specialize
in, say disk gear. With wrench and scope and Boolean equations,
I worked on, and learned, every part of the entire supercomputer
system. Seymour knows deeply about a narrow part. I know the
entire system to a fairly deep level. I fixed a bunch of bugs.
After 15 years and many new versions of CRAYs, I moved to Los
Angeles for family reasons. I went to work with Teradata putting
out 400-CPU parallel computers. More good stuff to play with!
Now part of AT&T, my work is on the software side, documenting
the huge Teradata Database System that moves all those CPUs in
parallel.
BENEFIT of BSEE
My EE education and my own electronics tinkering in ham radio
and other areas have been a huge advantage when dealing with
hardware designers.
No way could I have done well at the Chippewa Lab nor at Cray
without the EE knowledge. I could not have formed the close
personal relationships without the common language and viewpoint
of engineering.
BENEFITS OF TECH WRITING
As I said before, I have a wider view of the whole product
than any single engineer. I can see interconnect problems
no others can. I know the marketing approach, the sales story,
and the development problems. I also see a wider variety of
projects, because it (usually) takes less time to document a
project than to develop it.
Perhaps I am more mobile than an engineer can be, because Tech
Writing is done everywhere; only the subject matter changes.
The local chapter of STC, Society for Technical Communication
has writers in automotive, banking, petroleum, aerospace (few
left), medical, electronics, software, and many other fields.
Tech writers are not as strictly pidgeonholed as engineers
seem to be. We do have to keep up with new software of the trade
and new directions, just as an engineer must. But a manual here
is organized the same as a manual over there. We can move.
Many writers are independent consultants and doingtechwr-l -at- vm1 -dot- ucc -dot- okstate -dot- edu
well
these days.
BUSINESS VIEW
There is another point to make in comparing engineering and
technical writing.
The engineer designs and creates the product
to be marketed. The tech writer designs and creates the
documentation that makes the product real to the user
(especially in the case of software).
The engineer must exist and produce first, or there is no
product to market or document.
But if there is no marketing, the product goes nowhere and
the engineer is on the street again.
If there is no documentation, then marketing dies, support dies,
and the product dies. And engineers and marketers and support
engineers hit the street.
For you would-be-entrepreneurs, remember that you have to
have marketing and documentation. You better become very well
versed in engineering, marketing, and documentation to survive
in the marketplace. Business knowledge helps a HEAP, too!
ENGINEERS WRITE! (You will..., as AT&T says)
As an engineer you WILL write. You will write MOUNTAINS of
specs, test reports, requests for project approval,
justifications for project failures. You will educate, preserve
technical knowledge, convince superiors, and save your butt by
writing, writing, writing.
There is absolutely no way to get around it.
Our software engineers spend about 30% of their time writing the
specifications that allow linking foreign modules and products
to the software. User-visible feature specs. Software external
interface specs.
Hardware engineers write overall specs just to get the project
approved! Then the spec acts a sanity check as the design effort
goes through its agonies.
In older, fatter days, an engineer could count on a savvy
secretary to type up his scribblings and make them look coherent.
No longer. You get your own PC, your own copy of whatever flavor
Word Processor is in vogue, and then you are on your own.
ROAD TO RICHES! (Well, ah ...)
Managers promote competent people. That holds generally true. They do
not promote incompetent people, at least not knowingly. The easiest
way to look like an incompetent buffoon is to use poor grammar, poor
punctuation, and downright bad spelling that still gets through the
spellchecker.
In short, do you want to rise to fame and fortune? Then don't hang
a millstone of poor writing skill around your neck.
As Seniors, you have already been told this time and time again.
Shortly you will learn that the graybeards spoke truth. The best you
can do now is to continuously try to improve. Always:
- Read a lot to get the feel of good English,
- Write a lot (you will..) and correct yourself
- Write a lot and heed corrections from good writers
Good Luck to all of you! And if you need help on documentation,
contact the Society for Technical Communication chapter in your area.
ARRRIGHT! Enough of that. I have some stern words for you, Steve,
and your fellow students!
How in FLAMING BLAZES do you think you can get by with bastardized
English like you posted???? YOU CAN'T!!!!! Here are the corrections for
the most flagrant errors.
I am **an** Electronic Engineering senior with a Tech Writing Cert
*could break here* and I have a 30 minute presentation to do for my EE
senior seminar on Tech Writing. I want to open their eyes to Technical
writing as ***posibible*** employment or at least have them realize that
they will **likey** spend time writing regardless of what ***there***
actual title is. *see below* So what I am asking for is anyone who
is degreed in EE or EL and now is working as a technical writer full
time or people who wish they had **a** EE or **ELs** knowledge
**to do WHAT?? WHAT should they DO??**. Since the class is all
EE/ELs, I want to keep the **the** presentation fairly tightly focused.
*see below* comment. I suggest:
I am asking anyone who is:
a) degreed in EE or EL and now working as a technical writer, or
b) technical writers wishing they had EE or EL knowledge/ (or)
... an EE's or EL's knowlwdge
to contact me and (pour out their whole confused life story / tell me
how great they are / criticize my writing, WHAT??)
Learn, Steve, learn! We all keep on learning.
Truly Best Regards,
Dick Dimock
AT&T Global Information Solutions
El SEgundo, CA 90245 Spelling checked by human eyes, not
electronic eyes.