The first question students usually ask is about the importance of the degree; English degree vs. Technical Communication degree, or any of the minor variations of the two.
The short answer is, pursue your degree in the field you love. That's what college is about. It's supposed to educate you, not just train you for a job (that's what trade schools are about).
If you love writing and English literature and composition, then by all means go for it, get your degree in English. If the field you love happens to be technical writing, you'll find the education from a Technical Communication degree helps you more in your day-to-day work than other degrees. English (Literature or Composition) is closer to art; technical writing is closer to science. Both are crafts, however, and both are about writing. If you want to plan for a career in technical writing after you graduate, then the following advice should still serve you well.
Generally your college education is supposed to give you a solid grounding in the theory while your first job(s) will give you the practical, hands-on training. Unfortunately, employers are less and less willing, these days, to hire inexperienced 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. 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.
Like I said before, 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 down that path). College is only one way to learn theory; I suspect that most good-but-not-degreed writers have obtained, through their own reading and experience, an education to match or exceed the average college degree.
Education doesn't rely on formal schooling, and formal schooling is no guarantee that the student got an education. I sometimes like to comment about college, "I tried not to let my schooling get in the way of my education."
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.
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, write while you're flipping burgers and bussing tables, but write nonetheless.
Talk to the college computer lab managers and see if they need some introductory user docs or tutorials written. Find CompSci students working on graduate thesis software projects and offer to help them put the documentation together. Find professors who are working on software or technology projects and try to get involved. If you can find a professor who's familiar with your field - english, tech comm, or even a sympathetic CompSci prof - ask them to help you find outside projects you can intern with, or volunteer on.
Speaking of volunteering, check out a variety of organizations - not necessarily student organizations - and see if you can find opportunities to exercise your skills. You're more likely to find good opportunities to write if you look for non-profit organizations (and you get the bonus of knowing your effort is doing the world some good). But generally anything you're interested in might have an organization out there devoted to it, so look for one. The STC (see below) may be able to help you find volunteer opportunities.
With the amount of World Wide Web activities these days, look for web-based projects that you're interested in; most web sites are hungry for good content.
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.
A large part of your job as a technical writer will be managing your own writing projects and understanding how they fit into the management of the software (or other ware) development project. Part of this you can learn from practice, part of it you can learn from learning about project management research done on software development methodology (see suggestion 3, below). I've also suggested a book below that I think may be useful, Managing Your Documentation Process by JoAnn T. Hackos.
Over half the jobs in technical writing are in the computer industry. If you're reading this on the web, you've made a start. Get on the Internet and join the technical writer's mailing list (http://www.raycomm.com/techwhirl/). It's like being able to listen in (and ask questions) while a couple thousand professional technical writers talk shop. Meanwhile, go get some grounding in the basic theory and operation of computers and software.
Learn a little about programming. Take a class, hang out with some programmers, try some private projects. Most programmers are eager to share information - sharing information is what their culture is all about. Be patient - they may get frustrated trying to explain concepts you don't even know the words for yet (if I had a dollar for every time a discussion with a computer scientist doubled back for explanations of new concepts and terms, then doubled back again for the concepts behind the concepts...). This will also give you great practice and experience at dealing with technically skilled subject-matter-experts, which will be part of your job as a technical writer.
For an easy introduction to programming, you may want to check out some online, multiplayer games that allow you to program things inside the game. It's a good way to learn a bit about programming because it's relatively 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 (as of this writing) is ChibaMOO. Start a telnet session and connect to chiba.picosoft.com 7777 (that's port 7777; with most telnet programs you just type the number after the machine domain name; with GUI telnet programs there's usually a special box for the port number).
From there, type "connect guest", ask the folks you meet for advice on how to get started, how to learn about programming and how to get programming access. You may also want to ask them how to get and use a MUD client program (a program that runs on your personal computer and provides a friendlier interface to the game).
The C programming language was the most commonly used programming language in the software industry when I wrote the first draft of this document (in 1993 or thereabouts). C++ was going strong and gaining ground and Java was a dot on the horizon. These days C++ is a lot more common and Java is hitting it big, but C is still very strong.
If you want a book to learn about C programming, I can't highly enough recommend Kelley & Pohl's C by Dissection. For your own experimentation, I recommend getting one of the more modern programming environments, like Visual C++ or Borland's C++. These should be more fun for you to play with, as they allows you to build spiffy GUI-style applications more easily than standard C.If you seriously want to learn about how programming works, not
just dabble, check out a more structured language first. Pascal is a
good language for absolute beginners, because it
Note that historically Pascal was held in low regard by some programmers (particularly in the C crowd; there seems to have been a sort of intellectual/academic feud behind that), so you'll want to get your feet wet with C or C++ after you get comfortable with Pascal or Delphi, so you have a little more in common with them.
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 - and as a technical writer you will be required to do the most coping of anybody involved in the process. The program will always change, you will always have to do the most to adapt to the change, and you will always be the last to hear of the change, and have the least amount of say in the matter.
Read through back issues of the CACM (Communications of the Association for Computing Machinery) and IEEE Softare Engineering magazines at your college library, for articles on this topic. Read up on usability testing and usability engineering, because you'll likely become involved with them.
No writer wants to further 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 comfortable hiring you if you are familiar with the software they use for publishing. (If it's any consolation to the writers, software development professionals face the same sort of problem; management tends to see them in terms of the programming languages and tools they've worked with).
Find and work with the major desktop publishing packages. FrameMaker and Interleaf are the two big ones in the industry for technical publishing, but you should also work with PageMaker and Quark Express (quite popular in the magazine industry, I'm told), Microsoft Publisher, AmiPro, anything you can get your hands on.
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.
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 the whole thing, 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
This may be the companion book to Technical Editing. It goes into detail (sometimes excruciating detail) about the process of technical writing and how that process fits into the processes of a development organization. A lot of the content is based on work the Software Engineeering Institute has done on the software development process and organizational theory. A lot is based on Hackos' experience as both a professional tech writer and a professional tech writing consultant.
Usability Engineering
by Jakob Nielsen
A good solid grounding in usability engineering. One of the more popular works in the field. There are other good usability texts, but I don't have enough personal experience with them to make recommendations. You may be able to find some available via the web.
Jakob Nielsen also maintains the usability Alertbox, a web "column" about usability.
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 on techwr-l.
The Mythical Man-Month: Essays on Software Engineering
by Fred Brooks
Pub: Addison-Wesley
ISBN: 0-201-00650-2
Frederick B. Brooks' compilation of essays, The Mythical Man-Month, is a commonly-cited work on software project management and is considered definitive by many programmers. It's also getting outdated; most software projects these days aren't nearly as large as the projects Brooks managed, and the technology has changed a lot. 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."
Code Complete
by Steve McConnell
Pub: Microsoft Press
ISBN: 1-55615-484-4
The same author has another book, Rapid Development, published just recently, about more recent design methodologies. It's been highly recommended to me, but I haven't had a look at it yet.
In closing, good luck, but don't forget that you're in college to learn about life, not just about the job you want!