Re: Advice on English vs. Tech Comm. degree

["Steven J. Owens" <puff -at- NETCOM -dot- COM>]

Ed,

>          I am an English major here at Mansfield University (where
> the heck is that!?) and am interested in technical communication as
> a profession.  What I was wondering was what are the advantages of
> a tech. comm. degree over as English degree, am I missing some
> fundamental information?

     If you really want to make your living as a technical writer,
(which I don't particularly advse :-), you're better off with a
technical communication degree.  English (as in english lit, etc) is
closer to art while technical writing is closer to science (though
both are still crafts).

     English is worthy in its own right, though.  If you love writing
and english literature and composition, then by all means go for it.
If you want to plan for a career in technical writing after you
graduate, then the following information should still serve you well,
but college is supposed to educate you, not just train you for your
job.

     Generally your college education is supposed to give you a solid
grounding in the theory while your first jobs will give you the solid
grounding in the practice.  Unfortunately, employers are less and less
willing, these days, to hire college graduates.  Technical
communication degrees, while still properly focusing on the theory,
will take a more studied approach to the research and structure, which
will probably serve you in good stead.

     My own degree is in communications, with the curriculum split
between rhetoric and writing.  I realized, too late, that what I
really wanted to study was information science and cognitive
psychology, but note that those are merely the same topics that I did
study, merely from a different perspective.

     One of more experienced writers I've worked with has an
honest-to-god technical communications B.S. (note that it's a Bachelor
of Science, not a Bachelor of Art) and it showed in the studied way he
approached some of the issues we dealt with.  I benefited much from
working with him, although I wouldn't change my own past.

> Also, my school doesn't offer any kind of tech. comm. classes, what
> would be anyones suggestion in getting some sort of expierience in
> tech. comm.

     As I said above, the theory is what's important to you in the
long run.  It's the distinction between a degreed professional and a
skilled tradesperson.  This doesn't mean that non-degreed folks aren't
good writers (I'm not going to start THAT thread up again) but I
suspect most of the good writers who don't have degrees have obtained,
through their own reading and experience, an education to match or
exceed the average college degree.

     However, if you want to improve your ability to cope with the
workaday problems you'll encounter, and perhaps improve your odds for
getting a job, I'd suggest the following.

     1) Write.  Write some more.  Keep writing. Find opportunities to
do the kind of writing you're hoping to get a job at.  Write for
whatever you can get, write for minimum wage or write for free but
write nonetheless.

     Talk to the computer lab managers and see if they need some
introductory user docs or tutorials written.  Find compsci types
working on thesis software projects and offer to help them put the
documentation together.  Find professors, likewise, who are working on
software projects and try to get involved.

     Learn what the "big picture" is like.  Try to tackle a project or
two with a large scope - like 400 pages or so.  Try to get involved
with a project where you can do online help or contribute to the user
interface design or even do some usability analysis.

     2) Learn about project planning and management.  A large part of
your job as a technical writer will be managing your own projects and
understanding how they fit into the product developer's management of
the product.  Part of this you can learn from practice, part of it you
can learn from learning about software development methodology (see
suggestion 3, below). I've also suggested a book below that I think
may be useful.

     3) learn about computers and software.  Over half the jobs in
technical writing are in the computer industry.  Your presence on this
list is a good start, but get some grounding in the basic theory and
operation.

     Learn about programming.  Take a class, hang out with some
programmers, try some prviate projects. You may want to check out some
MOOs, a game-like multi-user environment that allows you to program
internal extensions.  It's a good way to learn a bit about programming
because it's realtively easy, there are lots of folks around willing
to help you learn, and you get to show off what you create to the
other users.  A good place to start is ChibaMOO.  Open up a telnet
session to chiba.picosof.com, port 7777.  To do that with basic
telnet, enter:

     telnet chiba.picosof.com 7777

     From there, well, ask the folks you meet for advice on how to
learn about programming and get a programmer flag.  Also ask them
about how to get and use a MUD client program (my favorite is the
mud.el extension to the EMACS editor).

     If you want a book to learn about C programming, I can't highly
enough recommend Kelley & Pohl's _C by Dissection_.  See if they've
come out with a Visual C++ version. Visual C++ should be more fun to
play with, as it allows you to build spiffy GUI-style applications
more easily than standard C.

     Likewise, you'd do well to learn what you can about the software
development process and related topics.  Having a better understanding
of the process in which you'll most likely be working will improve
your ability to cope with it.  Read through back issues of the CACM
(Communications of the Association for Computing Machinery) and IEEE
Softare Engineering magazines for articles on this topic.  Read up on
usability testing and usability engineering, because you'll likely
become involved with them.

     4) Learn about the tools of the trade.  No writer wants to
promulgate the common management misconception that writers are little
more than glorified typists whose software skills are more important
than their writing skills.  On the other hand, it's a simple fact that
an employer will be more likely to hire you if you are familiar with
the software they use for publishing.

      Find and work with the major desktop publishing packages.
FrameMaker and Interleaf are the two big ones in the industry, but you
should also work with PageMaker, Quark Express, Microsoft Publisher,
AmiPro, etc.

     On top of that, learn about any other PC, Mac, and UNIX-based
graphics programs, word processors, and desktop publishing programs.
If you can't demonstrate competence in a company's DTP software,
competence in a wide variety of packages will help to convince them
that you'll have no trouble getting up to speed on whatever they use.

Reading List
------------

     You will probably find the following books useful in learning
about the "nuts n bolts" of technical writing.

Technical Writing by Mills & Waters

     This was the text that my afore-mentioned coworker referred to
constantly.  I never had the time to sit down and really read through
it, but what I did read was quite useful.  I'm not sure where it would
be available; your college bookstore may be able to order it.

Technical Editing by Judith Tarutz

     This will teach you a lot, both about writing and about the
editing process.  You'll need to know something about editing to do
your own edits, performing peer edits, and about how to work with an
editor.  A very good, solid, workable approach to the topic of editing
technical writing.  I wish there were a companion book about technical
writing.

Managing Your Documentation Projects, by JoAnn T. Hackos

     I've just picked this up, after seeing a reference posted here.
It looks like it may be the companion book I was wishing for, at least
as far as project management.  I'm still getting into it, but I
already think it's well-worth the price.

Usability Engineering by Jakob Nielsen

     A good solid grounding in usability engineering.  One of the main
works in the field.  There are other good usability texts (I've seen
them recommended here, Dumas and Reddish, etc.) but I don't have
personal experience with them to make recommendations.  There are a
few usability documents available via e-mail or ftp.


Other Books
-----------

     I'd also suggest you take a look at Brockman's _Writing Better
Computer User Documentation_ and just about any of William Horton's
works on documentation and online help.  They've been highly
recommended in this forum.

     Frederick B. Brooks' compilation of essays, _The Mythical
Man-Month_, is a commonly-cited work on software project management.
Most softare projects these days aren't nearly as large as the
projects Brooks managed, but you'll still find a lot in there worth
reading.  It's a very readable, slim book containing fifteen essays,
each dealing with an aspect of project management.  My favorite quote
has to be from Chapter 10, the Documentary Hypothesis, page 111:

     "     First, writing the decisions down is essential.  Only when one
     writes do the gaps appear and the inconsistencies protrude.  The
     act of writing turns out to require hundreds of mini-decisions,
     and it is the existence of these that distinguishes clear, exact
     policies from fuzzy ones.

          Second, the documents will communicate the decisions to
     others.  The manager will be continually amazed that policies he
     took for common knowledge are totally unknown by some member of
     his team."

A close runner-up is from Chapter 6, Passing the Word, page 62:

     "     For the writing of a definition will necessitate a host of
     mini-decisions which are not of full-debate importance. [...]
     _Not_ trivial, however, is the principle that such mini-decisions
     be made consistently throughout."



     In closing, good luck, but don't forget that you're in college to
learn about life, not just about the job you want!

Steven J. Owens
puff -at- netcom -dot- com