Job Title: Technical Writer
Education: BA in American History, minor in Sociology, Middlebury College
Previous Experience: I was a box office manager for a local theatre group, which might sound unconnected to technical writing, but I learned two valuable basic skills there: 1) I honed my written skills and learned how to communicate clearly and succinctly with our subscribers and 2) I learned computer skills and word processing skills.
After being a box office/subscriptions manager, I became a Text Processing Specialist where I learned editing and worked with other technical writers at a software database company. There I prepared the tech writers' work for print and learned SGML, a text markup language that predated HTML. I was hired as a technical writer at a healthcare information company that grew tremendously; there I became Senior Technical Writer and supervised other technical writers.
I continued in that vein when I was hired by a different computer software company. Right now I do a combination of technical writing and creating web sites.
Job Tasks: My job is to prepare online materials and user manuals for computer software. Most of what I write appears online, but there are several books that are printed, such as installation guides or reference materials.
On a typical day I do a lot of talking to the people who are writing the computer programs (the developers) and the people who are testing the programs (the quality assurance testers or QA) to find out what they've been doing. Sometimes the developers will have meetings to show us what they've done. Other times, the developers will make parts of what they are working on available for us to "get our hands on" and try it out. But often I just get verbal descriptions of how things are supposed to work. When things are going really well, we've actually planned out in advance how the software is supposed to act.
I do a lot of planning and giving feedback about upcoming changes to our software. I try to represent the person who uses our software and think about whether or not our user would find the change helpful or difficult to use. I really like doing what's called usability testing, where we give a new person a task to do, and see if that person can complete the task with our software.
I also do a lot of writing, editing my work and other writers' work. I test out materials that I have previously written to make sure that they are still accurate. I offer suggestions to the developers, report mistakes (called bugs) to the QA team, and fix bugs in the documentation that other people have reported.
Best and Worst Parts of the Job: Best part is explaining how to use our software so well that someone new can use it successfully. Getting someone the right information at the right time is tricky, but very satisfying.
Worst part is finding out that you don't have the time to fix a mistake, whether the mistake is something basic like a grammar error or typo - or not describing the software well enough and leaving our customers unable to use our product.
1. Learn to touch type. No, really, learn it and learn it cold. Texting is not touch typing. You'll be grateful.
2. It is always possible to learn a new word processing application, but it is not always possible to learn how to listen to people and interact with them in a positive way. Sounds basic? It's not. You have to understand people where English is not their first language, when they are not very communicative. These people are not even in the same time zone as you are, maybe you'll never ever meet your co-workers in person! I've worked with plenty of groups of developers where I never ever met them because we were located in different parts of the world. You have to be able to communicate through written AND verbal mediums, and gauge people's responses without visual clues.
3. Join the Society for Technical Communication. (No, I do not work for them, but I am a member.) It is gives you helpful networking possibilities, workshops at a reduced rate, competitions where you'll learn a ton whether you are a judge or an entrant.
4. Don't be the first person to volunteer to take minutes at a meeting. Just because you're the writer does not mean you are the secretary.
5. When you start out in a new job, get your work reviewed by your manager, by your subject-matter-experts, and by someone in sales. Be humble, ask around. Get that feedback early and either implement the suggestions or explain why not.
6. If there is a training group in your company, these people are your allies. Try to work collaboratively with them, you can sometimes save each other work.
These schools offer particularly quick info upon request, and we have written detailed profiles for each (click school names to see the profiles).
Request info from multiple schools, by clicking the Request Info links.
Learning at Full Sail University has always centered around interaction and the exchange of ideas. Our online curriculum fully embraces this philosophy.
The inside stories from people actually working in the field.
Click a story title to show the story, and click the title again to hide it.
Career Stories are concise, real-world career overviews written by people relating their personal career experiences and wisdom. They provide invaluable insights and mentoring advice to students and career changers.
Most stories include:
Please also see our detailed information about Technical Writers, including: