I'd Rather Be Writing » Breaking into Technical Writing

Q&A: What should my major be for a career in technical writing?

Tom Johnson — Sat, 12 May 2012 16:47:02 +0000

I received the following question from a reader:

I’m a 20 year old college student and I just finished up my first year at a local community college and I was wondering what my major should be if I want to become a technical writer when I eventually graduate. Right now my counselors have me majoring in General Science (b/c my dream job would be to work as a writer at Scientific American) but I’m wondering if that’s the right path I should be taking. I’m new to this site but I’ve already found a wealth of great information by just browsing about. Any advice you can offer would be greatly appreciated. Thanks!

If your dream job is science writing, follow a science major. Remember that having skills to write is only one element of technical writing. Knowledge of the domain you’re writing about (for example, science) is equally important, if not more.

That said, I don’t know of many science-writing jobs. There are far more jobs for technical writers in the software industry than anywhere else.

If I could go through college again and choose my major once more, I would probably still choose English literature with an emphasis in creative writing, but also add a secondary major in graphic design. Reason being, the combination of graphics and text make an excellent combination.

Why not computer science? Well, the software I write about isn’t something that a degree in computer science would have necessarily prepared me for. I don’t have a strong interest in documenting APIs, so the more advanced computer programming knowledge might simply be lost on me.

Another possible route for a major would be to ditch writing altogether. If you already have good writing skills, pour your mind into science classes and write on the side. Become an Isaac Asimov. Knowing John Donne’s poetry and Charles Dickens’ plots won’t necessarily help in a career in technical writing anyway.

Whatever your major, technical writers are lifelong learners. Most professional technical writers fell into the profession from meandering paths. Some were anthropologists, others teachers, or philosophers, physicists, and botanists — you name it. They’ve all managed to develop the skills they needed to excel in the field. So does it really matter what your major is? Not really. Learn to think critically, ask questions, write well, and be patient. Those attributes will do more for your career than any specific major you choose.

—————

Photo from Flickr by Herkie

Blog Sponsors

Collaborative Post: Giving Guidance to a Masters Student about Technical Writing Careers

Tom Johnson — Thu, 14 Jul 2011 16:25:26 +0000

I received the following email from Anna, a literature PhD candidate who is considering changing career paths from teaching into technical writing. This is a collaborative post, so if you have advice to share, please add it in the comments below.

1. What is it like doing tech writing on a freelance basis? (My understanding is that you have a full-time, permanent position, but since you’re so active in the community, I thought you might have more insight about this than I do.) It has been difficult for me to adjust to sitting in the same cubicle for eight hours a day. It’s not intolerable, but I would be happier with a job where I could decide where I do my work (at least sometimes), and freelancing seems like one way to achieve that. Given some of what I’ve read about the profession, it seems as if permanent full-time jobs are starting to give way to temporary contract gigs anyway. So do you think freelancing is feasible way to go? Have you considered going the freelance route instead of the permanent route? If so, why did you decide against freelancing? Are there permanent jobs where the writer doesn’t have to be in an office for 40 hours a week?

I have never done freelance technical writing. The only freelance I do is WordPress consulting. I have a family to support, and I prefer the stability and benefits that come with a full-time company job. However, rather than freelancing, it’s more common to be a contractor — the difference being that a contractor works on site for a short period of time, whereas a freelancer perhaps works from home. A lot of people who contract really enjoy it. Employers will perceive less risk if you’re employed on a contract basis rather than full-time.

As for siting in a cubicle 8 hours a day, yeah, that’s somewhat of a drag. Your current job may have you doing more grunt work than is usual for more mid- or senior-level technical writing jobs. I do attend meetings almost every day (hence I shift from my cubicle chair to a conference room chair), but overcoming the sedentary nature of an IT job is difficult. I balance all the sitting with regular games of basketball.

If you want to move around, you certainly can — interviewing subject matter experts, interacting with users, attending project meetings, going in and out of your recording room, and so on.

2. You posted some slides that you used in an STC conference for a student-oriented presentation. One of the slides that I found particularly interesting addressed the issue of whether tech writing could turn out, for some, to be some kind of trap. The worry was something like this: what if I go into the field and decide I don’t like it? Will it be too late for me to go into any other field without having to start from scratch? You proceeded to list a number of different fields that you thought an experienced tech writer would be well positioned to move into. (One that I find particularly interesting is UX-related work.) But I’m a bit skeptical about this. Do you know people who’ve managed career shifts like this? If so, did they have to go back to school or do anything drastic to prepare for the change? I do like the idea that tech writing might be more flexible than my previous career path, but for some reason I have a hard time imagining someone moving from this field into another one. If you have any stories about people who’ve done that (whether they went into IT, development, UX design, information architecture or whatever), that would be very encouraging. (I couldn’t find any such stories.)

Many people see technical writing as a transitional career. There are a lot of related disciplines that tech writers can cross into: content management, XML, usability, information architecture, visual design, interaction design, content strategy, marketing and communications, e-learning, screencasting, project management, taxonomy, business analysis. If you have the incentive and drive to move into one of these related disciplines, you certainly can.

My comment about windows of opportunity closing is probably more focused on me. I have a family of five to support, I own a home, I’m 35 — to suddenly decide to try law or medicine, or to rethink my career path entirely (e.g., marine biologist) is pretty hard. Luckily, I’m quite satisfied with my path. I have found a lot of creative fulfillment in the tech comm field and its related disciplines. And that fulfillment isn’t in writing dry procedural tasks all day, which I will confess gets boring. I’m fascinated by information architecture and findability, screencasting, visual design, and blogging. It’s been a while since I last sat down and wrote a how-to topic. Today I spent most of my time writing a screencast script. Yesterday I edited several web articles.

Tech comm provides a lot of cross-disciplinary opportunities. The field is wide, with a lot of room to move around. Also, your background with literature will prepare you with an analytic, problem-solving mind — perfect for tech comm.

3. Suppose I decide to go full speed ahead with technical writing. Where do I go from here? If I do decide to stay in this field, I’d probably get involved with some open-source documentation projects (to build a portfolio, since the stuff I’m writing now is owned by my company), create a website where I could showcase my work, build up my technical skills a bit (I’m a novice programmer, and I could work on that some more), join STC (to network and also learn more about the profession) and perhaps find small contract jobs I could work on to make some extra cash and establish contacts. Do these sound like reasonable goals? Any other things I should shoot for?

I think you have the necessary experience and education to break into the field. Many jobs require at least 2 years of experience, so maybe stick with your current location or job for another year as you build up your portfolio. Then move to a tech hub city and find a recruiting agency that can help you land a job. Other tech writers can help ground and guide you.

Moving to the city where you want to work is key. Few companies hire out of state employees at the entry-level. If you don’t have to earn a lot of money, you could perhaps get by living in inexpensive housing. One day I’d like to move to California, but I’m not sure I could afford it, and I quite like my life here in Utah.

Blog Sponsors

Technical Communication Careers: Getting Started and Finding Your Niche (BYU Idaho Presentation)

Tom Johnson — Wed, 13 Oct 2010 08:40:53 +0000

Tomorrow I’m driving up to BYU Idaho to give a presentation titled “Technical Communication Careers: Getting Started and Finding Your Niche.” It’s part of their annual Pre-Professional Writing Conference for English and professional writing students. I like to go because I have an old colleague up there who teaches English (we spent 2 years in Egypt teaching at The American University in Cairo), and it’s always fun to visit with him.

Below are the “slides” for my presentation. I’m using WordPress rather than PowerPoint. You can actually click through the images just like you can with PowerPoint (once you are viewing the image details, click the image itself to move to the next one in the gallery). If you have any feedback about anything, let me know. I created these illustrations in Adobe Illustrator. I was actually going to insert them into PowerPoint, but I realized that when you view the PowerPoint show, it resizes the images and makes them a little blurry. Plus I’m weary of PowerPoint anyway and wanted to try something new.

Note: Several people have asked if they can use some of these images for their own slide presentations. Sure, feel free to do that. You can link back to my site with attribution if you want, but it’s not required.

Blog Sponsors

Students Contemplate Whether a Technical Writing Career Will Be Fulfilling

Tom Johnson — Thu, 30 Sep 2010 14:41:47 +0000

For the past couple of years in October, I’ve gone up to Brigham Young University Idaho to talk to students at their professional writing conference. I’m going up there again this year. In preparation, I asked my colleague who teaches there whether students still think of technical writing as a sellout/fallback career, or whether they’re more seriously preparing for an actual career in technical writing. My colleague responded:

They’ve chosen professional writing as a career because doing so is prudent (or at least more prudent than choosing creative writing or college teaching). They may wonder, however, whether they can really be happy in a career as a technical writer. The professional world is a bit of a mystery to them, and they wonder whether they’ll really end up content as professional writers. They sort of feel that they’ll never know this until they try it, but that after they try it, it’ll be too late to go back and do something else. There’s a sense of entering a career path sort of half blind. Anything you could do to answer whether they could really be happy in a career as a tech writer would help them out a lot.

I’m at a loss for how to respond to this student dilemma. How do you know whether technical writing is the right career path for you? I’m really hoping you can shed some light as to how I could help students resolve this dilemma.

A student contemplates whether a career in technical writing will lead to a fulfilled/content professional career

In previous collaborative posts, I created a Google doc to collect the responses, but in the last collaborative post, most people just added comments below the post itself. The latter method seems more practical. I appreciate any insights you may have.

Blog Sponsors

40 Foundational Books for Technical Writing

Tom Johnson — Fri, 10 Sep 2010 14:35:47 +0000

I received the following question from a reader:

I have semi-transitioned to a new position at my job where I’m responsible for creating and maintaining documentation for our systems, programs, policies, etc. I was selected for the position because I have written many tutorials for our applications to be read by new employees. Since I have no formal education in writing (I love to write, but I majored in accounting with a masters in information technology), I’d like to learn the basics of it. Can you recommend any books (I live in the US) which provide a decent foundation into the field of technical writing?

I asked my Twitter and blog friends to respond with their recommendations. Here they are (the name in brackets after the book is the person who recommended it):

Technical Writing, by T.A. Rickard, is a seminal work. You can find it in many academic libraries. You’ll be amazed by how the emphasis on fundamental writing skills hasn’t changed. [Mike Frasciello]

Managing Your Documentation Projects, by JoAnn T. Hackos, while 15 years old, still applies today for most areas of project management for technical communication projects. [Dave Brock]

Technical Writing 101: A Real World Guide to Planning and Writing Technical Documentation, by Alan Pringle and Sarah O’Keefe, is a good starting point. [Tom Johnson]

Technical Communication, 9th edition, by Mike Markel. I’ve taught several Effective Technical Communication classes for non techcomm majors such as engineering students, IT students, etc. using this book and the online resources. Most of them keep the book in their jobs as a reference on how to write for various situations. [Ben Woelk]

Managing Writers: A Real World Guide to Managing Technical Documentation, by Richard L. Hamilton. This provides a good overview for managers who are suddenly called to manage technical writers (and who have no idea what they do). [Tom Johnson]

Trees, Maps, and Theorems, by Jean Luc Doumont, is good for engineering students who have to write reports and other scientific papers. [Tom Johnson]

This isn’t a book, but listening to the backlog of podcasts on Idratherbewriting.com will give you a good foundation into the field. See http://idratherbewriting.com/podcastslist. There’s also a special collection of posts for students or other professionals transitioning into the field of technical writing: http://idratherbewriting.com/for-students. [Tom Johnson]

You could also listen to the latest STC sessions by buying the Summit @ a Click, which has about 90 recorded sessions on tech writing related topics. [Tom Johnson]

Technical Writing Wikiversity also provides a lot of good information online for free. [Tom Johnson]

Conversation and Community: The Social Web for Documentation, by Anne Gentle, provides a good approach to integrating technical writing with social media. [Tom Johnson]

On Writing Well by William Zinsser, a classic on non-fiction writing.

Elements of Style by William Strunk Jr. et. al., another classic for writing.

It might help to keep a few reference books on the shelf. Here are a few of my favorites: [Quinn Warnick]

Two classics on writing and revising: Writing with Style, by John R. Trimble, and Revising Prose, by Richard A. Lanham (Lanham’s Revising Business Prose is good, too, though it’s in desperate need of an update.) [Quinn Warnick]

If your reader isn’t opposed to buying a “textbook,” The Essentials of Technical Communication is pretty good. I’m using it in my tech comm class for the first time this semester and, so far, I’ve been impressed with it. It’s concise, practical, and surprisingly honest about the challenges and pitfalls of writing in technical and corporate environments. [Quinn Warnick]

Writing Tools by Roy Peter Clark — Written for Journalists, but is a great collection of articles on writing well and using good rhetoric.

Developing Quality Technical Information, an easy to read manual with plenty of example, written by technical writing professional and editors at IBM. [Seth Packham]

Audience, Relevance and Search: Targeting Web Audiences with Relevant Content, by James Matthewson and others, provides an excellent primer on writing for the web, keeping in mind SEO and other concepts. [Tom Johnson]

Cognitve Surplus, by Clay Shirky, explains why users want to contribute (and why sometimes they don’t)

Technical writing : a reference for technical writers at all levels, by Diane Martinez, published by Kaplan Pub. (2008). A new version (updated) is coming out at the end of 2010. I like this book; it has good information for new writers and for writers who have been in the ‘biz for awhile. [Adriana Harper]

Handbook of Technical Writing (9th Ed.), by Gerald J. Alred, Charles T. Brusaw, Walter E.Oliu. This is a reference book and I find it works nicely side by side with something like The Elements of Style (Strunk and White). [Adriana Harper]

Technical Writing for Dummies, by Sheryl Lindsell-Roberts. This focuses on the basics. Great for getting an insight into Technical Writing. [Anne-Marie Lansley]

Rapid Instructional Design, 2nd edition, by George M. Piskurich. This is great if you’re new to instructional design and e-learning. [Anne-Marie Lansley]

Practical DITA: an XML based architecture for authoring, producing, and delivering technical information, by Julio Vasquez. [Tom Johnson]

DITA 101: Fundamentals for Authors and Managers, by Ann Rockley et al [Tom Johnson]

Read Me First! A Style Guide for the Computer Industry

Style: Toward Clarity and Grace, by Joseph M Williams. The best book on the craft of writing that I’ve come across. All writing, all communication, can be improved by mastering a technique or two. But tech writing requires mastery of every single one of them. How come? Because your reader isn’t in a good mood when they’re reading your stuff. [Sharon Twiss]

Microsoft Manual of Style for Technical Publications. If you’re to document a UI or tell a user how to do something, this guide is invaluable. It encompasses the standard phraseology and “dogma” of telling a user how to do something. It has been the same shtick since 3.1.1, but it has set the standard of a users expectation. I too like the dummies/idiots books to get back to the basics. From reading your blog for almost a year, I think you have the technical side covered. [Mike Walsh]

The Elements of Technical Writing, by Gary Blake and Robert W. Bly [Mark Brennan]

Designing and Writing Online Documentation, by William Horton

Technical Writing: Process and Product (5th Edition), by Sharon J. Gerson and Steven M. Gerson. This book guides technical writers through the entire writing process — prewriting, writing, and rewriting.

Technical Writing Basics: A Guide to Style and Form (3rd Edition), by Brian R. Holloway. This book includes direct practical explanations, real-world examples, and a variety of “role-playing” exercises. [Rachana Khatri]

Is the Help helpful? by Jean Hollis Weber. Lots of checklists, lots of good advice for writing online documentation. [Rhonda Bracey]

Don’t make me think! by Steve Krug. Essential reading for anyone involved in any sort of design — web design, GUI design, product design, etc. [Rhonda Bracey]

Grammar, Punctuation, and Capitalization: A Handbook for Technical Writers and Editors, by Mary K. McCaskill (Langley Research Center) is a NASA guide for documentation. Though not strictly for software industry, this comprehensive manual provides extensive and detailed specifications for good technical writing. [Gautam Soman]

Online Technical Writing Textbook, by David A. McMurrey. This textbook is freely accessible to anyone who needs help with writing for business, science, and technology. [Rachana Khatri]

JoAnn Hackos’ book mentioned near the top of the list is top-notch but heavy duty stuff. Don’t read it first if you’re just starting out.
Also not a book, and a tad disorganized (it’s a blog, after all), but with engaging posts on a variety of topics relating to writing clearly: http://writing-rag.com. [Rogers George]

Blog Sponsors

Answers About the Field of Technical Writing for Students

Tom Johnson — Mon, 06 Sep 2010 16:15:51 +0000

Download MP3
Length: 27 min.

In this monologue podcast, I answer a student’s questions about the field of technical writing, including how I fell into it, what kinds of projects I work on, and other details. Her questions are as follows:

What did you study in college and where did you attend?
What degrees/certificates do you have?
Did you know what you wanted to do before you graduated? If so, what was it? Is it what you’re doing now? If not, why did it change and are you glad it did?
What is your current job title and description?
How did you come across your current job?
What did you go through to get this job? Applying, interview, training, etc…
How long have you held this position?
What activities, responsibilities, duties, knowledge, etc. does your position require?
What have you done to maintain your success in this field/position?
Have your position and/or responsibilities changed over your time with this company?
What past jobs have you had? Were they helpful when starting your current job?
Did you study technical writing in school or was this learned/gained through the employment that you sought and obtained?
What tools (including computer software) do you most frequently use? And what tools do you most highly recommend to other technical writers?
When you were younger, what was your dream job? What’s your dream job now (if it’s not your current job) and do you plan on trying to pursue it anytime in the future? How will you do that if you plan on it?
Had you heard of technical writing before your jobs that were in the field? If so, what did you think of it and when you got involved with it in your past/current employment how was it different/similar from your previous expectations?
Can you ever see yourself working in a position that doesn’t require writing or some form of technical communication? Why/why not?
How would you describe your personal writing style? Do you think that at work this style is stifled because of the nature of your work or restraints/company policy?
Why did you start your blog? Where do you get the ideas for your posts and topics from?
Have you ever considered quitting your current job to work solely on your blog? Why/why not?
Is there anything that you’ve ever had the urge to write about to include on your blog but you haven’t actually done it? Why/why not?
What advice, if any, do you have for me, a soon to be college graduate wishing to enter the field in the next year or two?

Blog Sponsors

Perspectives on a Career in Technical Writing: Responses from 16 Tech Comm Professionals

Tom Johnson — Mon, 30 Aug 2010 13:36:46 +0000

Students at Missouri State University asked me some questions about technical writing as a career. To provide a balance of opinion and perspective, I opened up the questions to my Twitter followers and asked them to respond as well.

What is your job title?

Eileen Potter: Senior Product Content Specialist
(in June I changed positions within my company, previous title was Senior Technical Writer)

Richard Rabil, Jr.: Technical Writer III

Susan Gallagher: Senior Technical Editor (temp)

Leisa Ashbaugh : Tech Writer

Patty Blount: Senior Tech Writer

Tom Johnson: Senior technical writer

John Paz: Technical Writer (TechWriterNinja on Twitter)

Anindita Basu: Information Developer

Chris Ninkovich: Technical Document Specialist

Jullio Vazquez: Senior Information Architect

Kim Nylander: Technical Writer

Grant Hogarth: Technical Writer

Rachel Houghton: Senior Information Designer

Kirsty Taylor: Team Leader: Technical Writing

Daniel Pintilie: Technical Writer

Kartikeya Dwivedi- Senior Technical Writer

Where do you work?

Eileen Potter : Eden Prairie, MN (suburb of Minneapolis)

Richard Rabil, Jr.: Gaithersburg, MD

Susan W Gallagher: Qualcomm, San Diego CA

Leisa Ashbaugh : Vendor at Microsoft, Redmond WA

Patty Blount: CA Technologies, Islandia, NY

Tom Johnson: LDS Church, Riverton, UT

John Paz: Carley Corporation, Orlando, FL

Anindita Basu: IBM India

Chris Ninkovich: Burnaby, British Columbia (Canada)

Jullio Vazquez: SDI, Durham, NC

Kim Nylander: SAS, Cary, NC (contractor for Greene Resources)

Grant Hogarth: South Jordan, UT

Rachel Houghton: Beaverton, OR

Kirsty Taylor: Brisbane, Qld, Australia

Daniel Pintilie: Freelancer, Brussels, Belgium

Kartikeya Dwivedi- ibruk Consulting, India

What preparation did you have for your current job?

Eileen Potter: B.A. in Advertising & Public Relations, 9 years retail operations (both field and headquarters positions; provided a great education about business, business issues, and customer relations.) Laid-off and re-careered into technical writing. After the layoff, 13+ years technical communications (User Assistance materials, SharePoint Site Admin, technical white papers, sell sheets, and other marcom materials.),

Richard Rabil, Jr.: Bachelors degree in Professional Writing. During school, did lots of journalism and freelance writing projects, plus a professional editing internship. Also worked one year as a tech writing intern before joining my current company full time. Currently pursuing a masters in tech comm.

Susan W Gallagher: 25+ years of experience as a technical writer, technical editor, and department manager

Leisa Ashbaugh: 11+ years experience as tech writer (also write marketing and technical marketing web content)

Patty Blount: 7 years in tech comm, as a writer and a manager

Tom Johnson: a bachelors degree in English and a masters in creative writing; jobs as writer/editor, copywriter, writing teacher; a fluency with technology

John Paz: B.A. English, Tech Writing track. 4+ years as a tech writer, 2 as a contractor, 2 in the simulation and training industry. My mother is also an English professor (she’s been prepping me since birth).

Anindita Basu: 10 years as a finance executive, then a switch. Just like that. Was always interested in writing though, and even in the non-TW avatar, had gravitated towards writing process manuals and instructions booklets.

Chris Ninkovich: 10+ years experience writing business and marketing communications. I graduated from the British Columbia Institute of Technology with an Associates Certificate in Technical Writing. As a kid, I used to LOVE reading instruction manuals for toys, games, IKEA furniture. Maybe that helped!

Julio Vazquez: 20+ years in technical communications in IBM, over 10 years in computer operations/programming/support. AAS in Electrical Technology, BS in Computers and Information Systems. Worked in many aspects of information production processes.

Kim Nylander: BA English, writing emphasis. Background in desktop publishing, retail, editing, photography, and 3D imaging. Working on a help desk. Writing professionally since high school. Hardware, tech, gadgetry, and gaming are all hobbies.

Grant Hogarth: BA English/Tech Theatre, 12y construction, 12y Theatre, MA Rhetoric (OSU Columbus), MS Technical Communication (Rensselaer Polytech). 18y experience as a TW.

Rachel Houghton: BA English Language and Literature, minor in Professional & Technical Writing. 14 years experience as a TW.

Kirsty Taylor: Working as a technical writing project manager, and before that a technical writer with my company. Started a B INf Tech at university, then switched after two years to a BA in Linguistics and Business German. I mushed it all together to get into tech comm.

Daniel Pintilie: BA in English and French, MS in Computational Linguistics and 6+y experience as a TW and sometimes developer/tester.

Kartikeya Dwivedi: Am a techie. Was always into Writing, and decided to make it a full time love affair. Got a freelance Content Writing jig, took up a Software Documentation and a Creative Writing Course, one thing led to another, and I found my calling. It’s been more learning on the job though.

What preparation do you wish you would have had?

Eileen Potter: Would have been nice to have had a basic understanding of graphic design, typography, and how visual design elements impact usability. Of course, now I think it would be interesting to take some user interface/interaction design classes.

Richard Rabil, Jr.: I wish I pursued visual communication much sooner and developed multimedia skills like doing screencasts, web-based tutorials, and voice-over narration. Also wished I had more experience with help authoring tools and context-sensitive help.

Leisa Ashbaugh: the 11 years so far serves me pretty well. When I started, it was a dramatic career change. I did a 9 month professional certificate program for Technical Writing & Editing at the University of Washington, and was very happy for that.

Patty Blount: Wish I’d finished my MS in TechComm before RPI cancelled their distance program for that degree.

Tom Johnson: I wish I had pursued a masters in tech comm or digital media rather than creative writing. Actually, it would be nice to be an interaction designer as well, since they’re held in such high regard in our organization, and their skills (usability, user analysis) overlap with tech comm quite a bit.

John Paz: I had a lot of the writing skills I needed after my first two years in college. I wish I minored in Tech Writing and majored in a more technical field, some IT-related, mostly because that’s what where a lot of my interests are, and because it would have greatly increased my earning potential.

Anindita Basu: I wish I knew a bit about adult learning behaviour. That would help me create more engaging stuff.

Chris Ninkovich: More knowledge about XML, DITA, single-sourcing. All that cool and hip stuff the kids talk about in the tech writing playground.

Kim Nylander: A few classes in graphic design and information architecture would have been useful.

Grant Hogarth: Project scheduling and management, UI design theory, instructional design.

Rachel Houghton: I wish I had known the “current software” at the time I entered the field. My university only taught Desktop Publishing using Quark Xpress, so I had to learn Framemaker on the job, using Frame for Unix 4.0. I wish I’d had a business minor. For this job, I wish I’d had more accounting and/or construction background.

Kirsty Taylor: For my first job, more technical understanding of telephony an IPv6, but generally, I learnt what I needed on the job. Now: knowledge in management, leadership, internationalisation/translation, and perhaps an MBA.

Daniel Pintilie: I learned a lot by working as a TW but I wish I had more time to study programming and IT architecture, project management and usability design.

Kartikeya Dwivedi: Agree with Anindita. Human factors study would have helped. Also a course in Usability.

What is your favorite task at work? Why?

Eileen Potter: I love being creative enough to solve the immediate communication “symptom” facing someone yet analytical enough to step back and determine a longer term solution that solves the true communication “problem”/ business issue. For example, someone asks for a System Limitations document but when you talk to the people who need the info, you realize that the real solution is a searchable System Limitations wiki that let’s people understand limitations introduced by combinations of internal and external tools/applications depending on the version. So, in the short-term, you deliver the Sys Limits doc as requested but you get the discussion going re: the Sys Limits Wiki (or spark better ideas from the team.)

Richard Rabil, Jr.: I love knowing a subject well enough to write about it to others and see them “get it.” Also love teaching technology to others using multimedia such as web-based manuals, screencasts, and help content embedded in interfaces. It’s also great fun to combine writing with visual design and page layout — in this way, tech writing is a really creative, rewarding endeavor.

Susan W Gallagher: editing a document: I find it both relaxing and interesting work.

Leisa Ashbaugh: Editing and writing. I like learning new technical info that I would have never otherwise come in contact with. And, I like writing succinct and complete procedure steps, and snappy marketing copy too.

Patty Blount: new media. Love researching new things like wikis, social networks.

Tom Johnson: I like creating screencasts and interactive media content more than anything else. People get the most excited about these kinds of materials. There’s a presumption that almost anyone can write, but almost no one knows how to create audiovisual materials. Most users prefer video/screencasts over written text as well.

John Paz: I like to write, but the material I write about is bland. The most joy I get is interviewing subject matter experts and discussing what they do.

Anindita: Writing. Creating movies. It’s because I love to communicate and this is what lets me “talk”.

Chris Ninkovich: Communicating with my team members and sharing ideas. I love socializing with people, and tech writing allows you to do that (believe it or not).

Kim Nylander: Learning about complicated concepts and figuring out how to explain them in plain English with illustrations (as needed).

Grant Hogarth: indexing, editing

Rachel Houghton: my favorite part is to edit, but I also enjoy being challenged to learn something new, or being able to occasionally do something different. At one job, I did not just write the documentation, but assisted in Marketing because of my Creative Suite skills.

Kirsty Taylor: I like editing, but rarely have time for it. I feel so hands off now, to when I was an individual contributor, that any time I can get my fingers in our tools, I’m happy.

Daniel Pintilie: I love creating task-oriented topics explaining step by step the functionalities of a software and adding/editing the visuals.

Kartikeya Dwivedi- I love the diverse writing work I get to do out here at ibruk. One day it courseware dev, the next day it is process documentation. So the challenge of taking up a new subject/domain, analyzing client needs and delivering customized documentation solutions is the best part of my job.

What is your least favorite task at work? Why?

Eileen Potter: providing hours estimates, defining schedules, tracking hours, anything repetitious: it is time that takes me away from my real job and I know there has to be a faster way to do it. (I understand people are just trying to estimate/track the actual cost of developing a product but I still don’t like it.)

Richard Rabil, Jr.: Being asked to “fix” poorly designed or written documents at the last minute with little to no understanding of the audience, technology, or context. Being asked to write a great product without having access to the readers / end users, and extremely limited access to the SMEs. Having to write tedious status reports and track every single task accomplished during the day. Oftentimes, I don’t do any writing or editing on the product; it’s all research, planning, or interaction with others.

Susan W Gallagher: editing source code comments: working with ascii text is tedious at best. I seem to spend more time fiddling with line length than I do actually editing

Leisa Ashbaugh: tracking tasks in various bug tracking apps, and reading/editing metrics

Patty Blount: Making PDFs. Hate them.

Tom Johnson: I hate writing documentation that users don’t need. I sometimes have to do this out of business continuity purposes — someone feels it’s important that we have a manual about how a program works, even though everyone who uses the program already is familiar with it.

John Paz: I agree with Tom Johnson above; I cannot stand writing documentation that’s not needed. I need a job no matter what, but to spend 40+ hours a week developing crap people don’t need is demoralizing.

Anindita Basu: Project Management. I hate it (no particular reason)

Chris Ninkovich: I agree with Tom as well. Nothing depresses me more than writing a useless piece just to please some manager.

Kim Nylander: Being asked to help write a document and being asked not to change the writing style, layout, or online help entry style.

Grant Hogarth: writing the same document over and over. Being “edited” by someone who has no idea what they are doing, but relies on grammar-school prescriptions and what they may have heard from someone in some previous office.

Rachel Houghton: Conditional text. Hate it.

Kirsty Taylor: I don’t hate it, but I can find smoothing the relationships between my team and other teams/individuals or my team’s concerns over issues emotionally draining to deal with.

Daniel Pintilie: I don’t like to document bugs and proofread documents written by developers.

Kartikeya Dwivedi: Unnecessary and unproductive meetings at client sites.

What skills do you consider essential to your position?

Eileen Potter: I agree with Richard below. I would also add…curiosity about the product, curiosity about the user’s business and how the product helps them, comfortable asking questions and pursuing good answers, not just the answer you were given. Able to distill bits of information and understand how they come together to provide a better picture. The ability to differentiate between developer-speak [SME input, difficult to code, proud of their technical accomplishment] and the impact it may or may not have on what the user actually cares about [solving business issue: User Assistance output].

Richard Rabil, Jr.: Master writing and style as an art and a craft. Know how to create usable visual materials, how to integrate audio and images with the text, how to do information architecture, how to research the audience, how to collect and incorporate feedback, how to negotiate with other team members, how to learn technology or complex processes and explain them to others, and how to plan for writing / editing challenges that will emerge later.

Susan W Gallagher: language, curiosity, attention to detail, technical acumen

Leisa Ashbaugh: good people skills, quick understanding of new concepts, looking for the “missing info” and of course, good writing

Patty Blount: Besides good writing? The ability to understand the technology I document

Tom Johnson: The ability to write, to create visual material, to learn applications quickly, to interact with project team members, and the ability to work extended periods of time alone.

John Paz: Good writing, which can be learned/taught. But one skill I developed that’s crucial, and some people have difficultly developing, is organization. Keeping files, documents, contacts, due dates, start dates, and other vital information organized will make your life easier in every way, and makes your data invaluable to other people.

Anindita Basu: The ability to categorise info, the ability to prise info out of SMEs, and the ability to translate the info to whatever I am writing/creating.

Chris Ninkovich: Communicating with others, thinking logically, being able to learn new things quickly. Also, a love of technology is good to have, too.

Kim Nylander: Writing skill, definitely, and also a passion for what you are writing about. Be a diplomat, evaluate all sides of a doc project, and have a good “user hat.”

Grant Hogarth: Organization, active intelligence, a high tolerance for stupidity and corporate politics, being able to “think like the user”.

Rachel Houghton: Writing skill, time management, people “management,” the ability to see beyond just your role, and how tasks from others impact what you do (and when you deliver). Not being afraid of technology or using a new software tool.

Kirsty Taylor: time management, interpersonal relationship skills, good memory, decent technical understanding (I work will all development teams in our company), managing upwards.

Daniel Pintilie: Writing skills, time and project management abilities, easiness in communicating to the SMEs, translating the technical into plain simple language, editing images, etc.

Kartikeya Dwivedi: Flair for Writing, Interpersonal skills, Communication skills, Language skills and an ability to learn thing quickly.

What skills do you think are important for every technical communicator?

Eileen Potter: In addition to the list above, realize that a “tech comm career” is a moving target and you will always be a novice, intermediate, expert at something in the Tech Comm continuum. As a result, have a life-long passion to pursue the knowledge you need for a particular moment/project in time!

Richard Rabil, Jr.: Same as above.

Susan W Gallagher: language, curiosity, attention to detail, technical acumen

Leisa Ashbaugh: see above answer

Patty Blount: assertiveness to battle the “anyone can write” mentality, advocating for users, a solid grasp of grammar, the ability to learn new tools quickly, the desire to change as business needs evolve

Tom Johnson: Same as above. I think it’s important to position yourself in the organization as being more than just a writer. It can be very easy for project managers to pigeonhole you into a documentation-only kind of role, when really you can contribute so much more, such as interface text, workflow, video, e-learning, and more. Knowing how to lift yourself out of an organizational pigeonhole is an important skill.

John Paz: Attention to detail, for sure.

Anindita Basu: Curiosity

Chris Ninkovich: If you are going to work in the software industry, know some basic code languages. Know basic HTML. Figure out XML. Learn how to write “topics”, not manuals. Learn about educating adults. Never stop adding to your “skill tool-belt”. Be prepared to wear a lot of hats in your career as a technical communicator.

Kim Nylander: Attention to detail. Watch current and upcoming trends for new skills to add to your skills bucket.

Grant Hogarth: ability to abstract principles from concrete examples, think about how the documents are likely to be used by the reader, solid writing and editing skills.

Rachel Houghton: Same as above.

Kirsty Taylor: Good communication skills, interpersonal skills, and an inherent curiosity: we can’t always rely on someone writing that design doc or telling us what to find: we have to find it and document it.

Daniel Pintilie: Transforming the complex technical world into a familiar, clear and friendly environment for the user/reader meaning that a technical communicator thinks first about the audience and the best way to convey the technical information into readable and useful information for the target audience.

Kartikeya Dwivedi: The aforementioned skills, attention to detail (which kinda grows on to you in this field).

Do you use visuals in your work?

Eileen Potter: Yes, process flows, screenshots, PowerPoint SmartArt. One area I’m trying to improve upon is designing true infographics where the text, the visual, and the concept they communicate are tightly integrated.

Richard Rabil, Jr.: Frequently. I try to use screenshots, process diagrams, icons, colors, page layout, and other such visuals as much as possible. Effective use of white space is critical too. In my experience, people learn and/or “get it” more quickly when pictures are involved along with the writing–or in place of it.

Susan W Gallagher: sometimes

Leisa Ashbaugh: Not currently. But I do think they are so important. Wish I had more training/experience in that.

Patty Blount: yes, definitely. People have different learning styles so I try to address that in my work. I use Visio diagrams to explain concepts or show system architecture, screen shots to eliminate confusion. I recently created some YouTube videos to give users who won’t “RFTFM” another vehicle for learning product use.

Tom Johnson — Yes, visuals are critical. Visual material is the most effective type of learning material, in my experience.

John Paz: Oh yes. And that’s another favorite task of mine, learning how to use graphic tools.

Anindita Basu: Not in user manuals, where I try to avoid them as far as possible unless it’s a complicated task flow or an architecture that just cannot be explained through words. But yes, in movies (where I try to avoid text as far as possible).

Chris Ninkovich: All the time. So learn how to use PhotoShop and Illustrator (or have a graphic artist as a friend.)

Kim Nylander: Some times the most effective communication is a graphic and not text. Any graphic that helps the reader better understand the content is good. Gratuitous graphics are a waste of space.

Grant Hogarth: It depends on the document. Some benefit greatly, while in others it’s just eyecandy.

Rachel Houghton: For the first time in my life, I’m not doing visuals in my documentation. I wish I could, but the screenshots and visuals are only used in the training department materials, and the training department is a separate department from the information design

Kirsty Taylor: We have some flow charts, but we stopped using most screen shots a few years ago. Internationalisation and keeping on top of thousands of screens is a big challenge.

Daniel Pintilie: Yes. I use visuals whenever is necessary.

Kartikeya Dwivedi- As they say, a picture is worth a thousand words.

If so, how are these visuals generated?

Eileen Potter: Visio, Full Shot, Snagit, PowerPoint, MindManager, MS Paint (I’m with you John!), MS Clip Art online.

Richard Rabil, Jr.: Snagit, Visio, PowerPoint, Microsoft Expression.

Susan W Gallagher: by me, either in Visio or Illustrator

Patty Blount: Visio, Photoshop, Hypersnap, Captivate

Tom Johnson: Captivate, Visio, Photoshop, Snagit, Illustrator. It really depends on what you’re creating. Often you need more than just a screenshot. You need to illustrate a concept.That’s more difficult and require some creative and technical skills.

John Paz: MS Paint (stop laughing, it does the job), GIMP, Photoshop (rarely, prefer GIMP), Visio, PowerPoint, and even Word.

Anindita Basu: Hypersnap, Viewlet Builder for basic screenshot and for movies. If I need a task flow, an architecture diagram, or some such picture, we have a dedicated Graphics department to help us make cool pictures from the back-of-napkin diagrams that I can’t better.

Chris Ninkovich: SnagIt (for screenshots), Adobe Captivate (for training pieces), PhotoShop, Illustrator, Visio.

Kim Nylander: SnagIt, Pixelmator, Omni Graffle, Concept Draw

Grant Hogarth: Screen captures, Photoshop, Illustrator, Balsamiq Mockups, wireframes, and work either contracted fopr from a graphic artist or purchased from stock.

Rachel Houghton: In previous jobs, I used screen captures (SnagIt), Photoshop, Illustrator, and MS Visio.

Kirsty Taylor: Microsoft Visio.

Daniel Pintilie: SnagIt, Visio, Photoshop

Kartikeya Dwivedi- SnagIt, Visio, Paint.

About what percentage of your time on the job is spent on writing (as opposed to researching, training, etc.)?

Eileen Potter: Writing 30%, researching 15%, planning/ meetings 30%, UI Review 15%, travel 2%, black hole of email and other time-suckers 8%

Richard Rabil, Jr.: Writing 25%, researching 25%, planning and editing 25%, working with others 25%

Susan W Gallagher: 50%

Leisa Ashbaugh : Editing 30%, Writing 20%

Patty Blount: Actual writing, 25%. The rest is research, edits, and publishing

Tom Johnson: Writing, 10 percent. Research, 20 percent. Tools, 20 percent. Meetings, 20 percent. I don’t know where the remaining 30 percent goes.

John Paz: First off, lol at Tom Johnson’s answer. Writing: 20%, Research: 30%, Planning: 20%, Meetings: 10%, the other 20% is spent doing things that don’t matter, like filling in surveys on the job.

Anindita Basu: 50%

Chris Ninkovich: Writing: 10% Research and Planning: 60% Working with others: 20% Drinking massive amounts of coffee: 10%

Kim Nylander: Writing 25%; Editing 25%; Research, planning, collaborating: 50%

Grant Hogarth: Writing 55%, image creation/manipulation 25%, editing 10%, bug logging 10%

Rachel Houghton: Writing 50%; Project Management 20%; Research 20%; 10% collaboration.

Kirsty Taylor: 5-10%, and that’s probably project plans and reports, not the real guts.

Daniel Pintilie: 30%. The rest is research, planning and interviewing SMEs.

Kartikeya Dwivedi- 40% for a solo project. Would differ on multi person projects though

Approximately how much of your time is spent collaborating with others?

Eileen Potter: At least 30%

Richard Rabil, Jr.: About a quarter of my time. This includes working with SMEs, managers, and if possible the end users or readers.

Susan W Gallagher:: 10%

Leisa Ashbaugh: 20%

Patty Blount: We are shifting to Agile; about half of my day is spent with others now.

Tom Johnson: Probably 20 percent. I should collaborate more than I do, not just with other project members, but with users.

John Paz: not nearly enough. Less than 10%, almost exclusively during meetings.

Anindita Basu: the remaining 50%.

Chris Ninkovich: 20%

Kim Nylander: Probably 20% collaborating (with Research and planning taking up the other 30% mentioned above)

Grant Hogarth: very little at my current job — a lot at others.

Rachel Houghton: 10%

Kirsty Taylor: 75%

Daniel Pintilie: Depends on the project. Sometimes very much, sometimes rarely.

Kartikeya Dwivedi- A good 30 %

In what ways do you work with others (technicians, designers, developers, editors, users, technical illustrators, etc.)?

Eileen Potter: read project wikis from developers, share docs & meeting spaces via SharePoint, meet w/ internal SMEs (product managers, client consultants) for creating speaking abstracts and presentation materials, team members for editing and feedback. Marketing for more complex graphics. Email for more detailed q’s; use IM for quick bits of info; share desktop with people in global offices.

Richard Rabil, Jr.: Work with SMEs (such as developers, business analysts, CEO, managers) to get the “big picture” business goals, to brainstorm on how to convey a story or message, to get specifics on how a technology or process works, and to get feedback on accuracy, etc. Work with other writers and designers to craft the product. Work readers or end users to understand their needs and processes, and to get their feedback on initial drafts or prototypes.

Susan W Gallagher: work with developers to get information and have them perform technical reviews on completed material; occasionally collaborate with other writers.

Leisa Ashbaugh: Meetings with service management team, hallway conversations, technical reviews and questions via email

Patty Blount: Developers (email) to gain product understanding, product management for project planning information and product marketing to reach customers. We are only now starting to use collaboration tools like SharePoint and wikis to share information.

Tom Johnson: I work with these other roles on a regular basis. Interaction designers often need help with interface text. I often go to developers to ask questions about functionality. Quality assurance engineers are helpful to clarify bugs. And users are key to other kinds of information, such as the tasks they perform, the language they use, the kinds of help formats they need. I can outsource technical illustrations and editing to another department, but I often don’t do this because it takes too much time.

John Paz: Mostly to obtain data I can’t get myself. Or to have an expert proof something I researched. My manager has to proof my docs before they go to the customer, and my customer can sometimes reply back with suggested edits.

Anindita Basu: With the dev team (to get the most of the info coz they’re the SMEs), with the QA team (coz they catch bugs, come up with workarounds, and have slightly more “customer” focus than dev), with editors (for doc structure and language), with info architects (for doc organisation, to decide what kind of materials will be produced, to troubleshoot production issues), with managers (because they write our appraisals ), with other writers on the team (to generally toss ideas about, gossip, and share jokes no one else gets)

Kim Nylander: I work with system administrators to document the procedures specific to supported operating systems and hardware. This material is then organized and presented on the group’s wiki. I also edit/write documents and create illustrations for other groups as requested.

Grant Hogarth: interviewing SMEs, discussing bugs with QA, and trying to keep Project Managers apprised of what is going on. I’m the sole writer here.

Rachel Houghton: Attending release team meetings weekly, attending release deliverables (working with printer/customer delivery), I’m in an Agile environment, so my I have two team members within 10 feet (the other half of the team is remote). I provide information to the training department as I receive it about new features: there’s often a disconnect between engineering and training: I’m the bridge. I’ve been asked to review the text for clarity in new dialog boxes, and I’m invited to sit in on feature demos and development meetings.

Kirsty Taylor: Most of my work is with others: liaising with project managers, development managers, my team, development team members, product management. I’m working with them to ensure their content deliverables are being created, dates/scope is negotiated, translation requirements.

Daniel Pintilie: As a freelancer, I work mostly with SMEs and request information about the product and I take part in some testing.

Kartikeya Dwivedi- Do my own edits, illustrations and process flows. Developers are the SMEs, and my interactions with them are to understand the application and point out usability issues. Have been trying to get direct end user feedback, or get in personal touch but that’s a losing battle for now. In my current process documentation jig, I am arranging mock ups for processes and it is helping BIG time.

What are your major sources of complaint and satisfaction on the job?

Eileen Potter: Sources of complaint: tech writing deadlines never slip although the deadlines of all other depts do, thus TW is regularly compressed. Source of satisfaction: I like helping other writers or employees when they are struggling w/ tools or content; I’m currently enjoying writing across all product lines in my new position.

Richard Rabil, Jr.: Sources of complaint: Working over time, dealing with last-minute stressful projects, not really knowing how effective the final written or design product is, not being able to use the latest technologies (I wish I could use more graphics, audio, and interactive media), not given enough time to do quality writing and design. Sources of satisfaction: Using the written word to make a living, working with a great team of intelligent people, seeing when a written or designed product gets high approval, being acknowledged as a good writer whose opinion matters, and getting positive responses from readers.

Susan W Gallagher: Satisfaction is from interesting work and good people to work with. Only complaint is that there is sometimes not enough interaction with others on the team

Leisa Ashbaugh: satisfaction for me comes when others appreciate my work. A simple “thanks” makes my day. Complaint: crazy, broken systems for tracking complex work items.

Patty Blount: Complaint: I request reviews, get no feedback, release content and then get a flood of complaints that the guide is wrong. Satisfaction: When customers take the time to notify the company that the documentation helped them.

Tom Johnson: Major sources of complaint: loneliness, sedentary-ness, feeling that no one uses the documentation, being required to create old help formats rather than interactive media, underbudgeting from project managers (so I don’t have enough time to create good help), being excluded from the product creation process until near release or even post-release. Sources of satisfaction: Empowerment with tools, exploration of new media and forms of learning, interacting with project teams in IT environments, stable work with good pay, low-stress, freedom to innovate.

John Paz: Complaint: My work doesn’t matter and is excessive to requirements, I live in constant fear I’ll lose my job. Satisfaction: technical writing is projected to have 15-30% job growth over the next decade. Complaint: I rarely get to do any of the cool stuff I worked on during undergrad. Satisfaction: I get to learn new things all the time, I get to work under tight deadlines (otherwise I slack off), and I get to write for a living (invaluable).

Anindita Basu: Major source of complaint: UI changes, code changes much after “decided” freeze dates. Major satisfaction: Overhearing someone say, “Heh! It’s there in our docs. Just go to this page … and then ask me only if you still don’t understand”.

Kim Nylander: Complaint: Being told, “I don’t know why you bother. No one reads the manuals any way.” Sigh. Have had that attitude amongst coworkers at several past positions. Satisfaction: Getting an email saying “We have documentation for that now on the wiki…” or “Did you see this article…?” Having coworkers who come in and say “hey I had this idea for a document…”

Grant Hogarth: Satisfaction: hearing that a doc I wrote helped clinch a sale, knowing that I’ve done good work, even if others don’t really recognize it. Dissatisfaction, being treated as just an automated typewriter, one that has no idea of what might improve the product or process.

Rachel Houghton: Complaint: hearing the old “no one reads the manuals anyway”: when my help feedback system clearly shows that the users are accessing software help (and which version too). Satisfaction: currently, it’s knowing that I’m providing an extra value to the team and getting recognized for going above and beyond when necessary.

Kirsty Taylor: Complaint: Working with some of the negative aspects of significant downsizing over the past 18 months and trying to keep my team together and focussed, regardless of what might happen around us. And when dev managers try to tell me how to write doco/what standards to use. Satisfaction: I have a darn cool team who’ve made some great innovations in the past year or two: things that we’d been trying to get to for years with single sourcing. I love working with I18N and translation, it really complements my linguistic and German experience.

Daniel Pintilie: Complaint: Having to explain why I do my job and why is important because not all the people in IT business know, requesting feedback without answer and having no certainty that the deliverable complied. Satisfaction: working with different people, learning new things every day, interviewing interesting people often and sometimes a thank you that counts a lot.

Kartikeya Dwivedi- The grouse is to quantify our work and commercials, as out work is not something completely measurable. So, it is mostly a time taken and money asked complaint.

Satisfaction comes with finishing the project, and by going that extra mile for the client, give them more than they asked for. And yes, repeat business

photo by Valerie Everett

Blog Sponsors

“Tom Johnson: A Modern Day Technical Writer” — NIU Article

Tom Johnson — Mon, 17 May 2010 04:16:19 +0000

"Tom Johnson: A Modern Day Technical Writer"

Alex Otil, a student at Northern Illinois University, recently interviewed me for an article titled Tom Johnson: A Modern Day Technical Writer. It’s a short article probably mainly of interest to students thinking of entering the field of technical writing. Students will also find the newsletter as a whole full of relevant information about entering technical writing.

By the way, the title of the article definitely deserves a follow-up from the opposite perspective — a spotlight of an ancient technical writer. (If you click the link to read the PDF, it’s the last article.)

Blog Sponsors

Podcast from BYU Idaho Professional Writing Panel

Tom Johnson — Thu, 15 Oct 2009 13:53:21 +0000

Download MP3
Length: 50 min.

Last week I was up at BYU Idaho at a writing conference for students looking to enter professional writing. This is a recording of a panel I participated on with two other writers, Scott Cameron and Keith Harten. The three of us (two technical writers and one editor) answer questions from students for about an hour. For students looking to go into technical writing, editing, or other professional writing careers, this podcast may answer a lot of questions.

I'd Rather Be Writing » Breaking into Technical Writing

Q&A: What should my major be for a career in technical writing?

Blog Sponsors

Collaborative Post: Giving Guidance to a Masters Student about Technical Writing Careers

Blog Sponsors

Technical Communication Careers: Getting Started and Finding Your Niche (BYU Idaho Presentation)

Blog Sponsors

Students Contemplate Whether a Technical Writing Career Will Be Fulfilling

Blog Sponsors

40 Foundational Books for Technical Writing

Blog Sponsors

More Students Questions about Technical Writing

Blog Sponsors

Answers About the Field of Technical Writing for Students

Blog Sponsors

Perspectives on a Career in Technical Writing: Responses from 16 Tech Comm Professionals

What is your job title?

Where do you work?

What preparation did you have for your current job?

What preparation do you wish you would have had?

What is your favorite task at work? Why?

What is your least favorite task at work? Why?

What skills do you consider essential to your position?

What skills do you think are important for every technical communicator?

Do you use visuals in your work?

If so, how are these visuals generated?

About what percentage of your time on the job is spent on writing (as opposed to researching, training, etc.)?

Approximately how much of your time is spent collaborating with others?

In what ways do you work with others (technicians, designers, developers, editors, users, technical illustrators, etc.)?

What are your major sources of complaint and satisfaction on the job?

Blog Sponsors

“Tom Johnson: A Modern Day Technical Writer” — NIU Article

Blog Sponsors

Podcast from BYU Idaho Professional Writing Panel

Blog Sponsors