The skills technical writers rely on

It's the start of Fall semester, and technical communication students want to know what kinds of skills technical writers and technical communicators use all the time. We asked our community: What's one skill that you use a lot? Here's what they shared with us.

AmyJune Hineline recommends learning about style guides:

Technical writers should be familiar with a few style guides. It's essential to understand the rules around localization, number formats, punctuation (not every style guide embraces the serial comma), code formatting, etc.

Chris Hermansen recommends learning how to write a good report:

In my consulting business, I feel as though I'm constantly at war with people over how to write a project report.  If you plan to be a consultant, remember that clients hire you to answer their questions - ideally, maybe even some questions they haven't thought of or didn't articulate fully when they hired you.  So when you write the report that is supposed to answer their questions, make sure that it does so!  Also, consider the following potential document structure:

1. Executive summary (really, just one page if at all possible and never ever more than two pages);
2. Introduction (very briefly, the context and scope of the study)
3. Summary of results (question or concern posed; what was discovered; next question; next answer... in as clear and brief a form as possible)
4. Recommendations (having understood and answered the questions, what else will you recommend?)
5. Appendices (everything else, in as much detail as seems reasonable for the audience - methodology, sources of information, detailed results, study timeline plan vs actual, CVs of study team, whatever; if you feel the need to tell a story, this is the place)

The goal should be to expose all the information needed to make decisions in sections 2 - 4.  The executive summary, rather than providing all the meaningful stuff in very brief form for people with short attention spans, is really more of an invitation to read the report, at least until the end of section 4; so yes, include the most important results and/or recommendations but make sure the way those are included encourages further reading.  The purpose of the Appendices is twofold: first, to document what was done and how for the curious or skeptical reader; and second, to expose the secondary information that was necessary to arrive at the results and recommendations.

Ideally, the Introduction should consume no more than two or three pages; the summary of results, less than 10 pages; and the recommendations another two or three pages.  Of course, some studies have intrinsically large numbers of items studied; but the seasoned writer, when confronted with that situation, will look to grouping those items into units of similar characteristics that are relevant to the study and explaining the characteristics of each group.  A study of the social risk of the non-conventional renewable energy portfolio of a big energy company might have a hundred or more small generating stations spread around the country; but the overall parameters of the study will permit their grouping together - for example, the facilities near communities opposed to local energy generation projects; the facilities within high tourist value zones; and so on.  The appendices may well have one page for each asset, but the report will not - one page per asset is data, not information.

Jim Hall says it's about getting things done:

The most important skill is getting stuff done. You can't keep rewriting things all the time, so it's critical to know how to tackle a project and get it done on the first attempt. Start by analyzing the request and understanding what you need to do to complete it. What materials do you need, what other information do you need to collect? What other resources do you need to do it, and who can help you? How will you arrange the information when you write it? Is the final product a web page, a PDF, an ebook, a printed document, or some other output?

Once you have identified all the components to the project, identify a work plan to get it done. You might be working on several projects at once, so you need to know how to divide your time effectively. That might mean allocating dedicated time to work on the project every day, so don't be afraid to use defensive calendaring to give yourself uninterrupted time to do it.

And then, just do it. Deliver it on time, then move on to the next project. If you can get stuff done, you'll be valuable.

Seth Kenlon says debugging skills will help you out of a jam:

Debugging. Whether I'm doing technical writing, or programming, or setting up a new computer, the skill I use most is testing all the things in a systematic way. The workflow of troubleshooting is vital, because sometimes things break in unexpected ways.

Computer Science is a science. No matter how we feel about digital culture, ultimately its foundation is binary. Something is either True or False. So develop a hypothesis, and test it until it's proven. Then move on to the next hypothesis.  Don't write off failure as a personal problem. Blame the technology, and then figure out what happened.

It's a skill that'll improve the tech you're writing about, it'll improve how you've written about it, and it adds to your personal store of knowledge and understanding.

Robin Bland says recent graduates should know how to work with real files:

One skill I see lacking in new graduates is understanding about files and folders. And maybe that's not surprising. "The Cloud" has been the standard mode for a long time, like Google Docs since the mid-2000s. A student who graduates today was like 3 years old when Google Docs came out. For their entire lives, they haven't had to think about files and folders, they just search for everything. Where did you save that file? They don't even know what that means.

But in our office, you still need to know how to organize things. You can't just search for everything, location really does matter. If you're working on a DITA project, your DITA editor works on real files. If you just dump everything into one folder, that doesn't work when a project has several thousand topics and assets (think Concepts, References, Tasks, images, and styles).