(Inspired by this article: 10 Skills Developers Should Invest In for 2014.)
I'm a tech writing project manager, so this is just my two eurocents' worth. An actual writer or a manager may have and probably does have a different idea of what consists a basic competence set. I work mostly with projects in the IT business, and with a combination of resource hire and "full" projects.
So, in no particular order, here are the 10+ big things I expect any tech writer to be able to handle:
1. English
You have to be able to speak and write grammatically correct English. This is basic requirement #1. Sorry. Most companies in Finland write their products and their documentation in English even if their corporate language is Finnish, mostly to keep down localisation costs. Otherwise, not only are you forced to translate from FIN to ENG when you stick a toe outside the border, but translating from Finnish into any other language is more costly than using English as your source language.
It also helps if you can draw on extensive knowledge of orthography and grammar to justify yourself to SMEs who think they know English but don't ;)
2. Information Design
You have to know how to structure a document from scratch. Not many projects you work on will require this, but it's a basic qualification that falls under the heading of "know how to write".
If you can't do ID, then you always have to have someone else plan your documents for you, and it limits the type of project you can do.
3. HTML and CSS
You have to know at least the basics of how they work and be able to edit raw HTML. Bonus points for being able to build a site from scratch.
4. XML and DITA/DocBook basics
Know how XML works and why. Most documentation today already happens in XML in some way, or if not XML then some other structured language. DITA and DocBook are the most frequently used architectures in technical communication.
5. Use Microsoft Word in a way that doesn't break things
Word is to tech writing what boiling potatoes is to cooking.
Know how to use and troubleshoot styles, cross-references, TOCs, images, and numbered and bulleted lists, to name just a few. You have to know better than to use direct formatting in anything but the most throwaway of docs.
You should also have an understanding of what is determined by the template and what is not, and how it's done. Bonus points for being able to create usable templates from scratch.
6. Have the basics of at least 3 authoring tools apart from Word
FrameMaker, RoboHelp, Doc-to-Help, Author-It, Madcap Flare, oXygen, Arbortext, Serna, XMLmind... Take your pick, but know at least the basic functionalities and requirements of some of the above. I don't mind whether they're help authoring tools or document authoring tools, XML or proprietary, just know a good selection.
7. Edit images
Know your way around image editing software. You have to be able to crop images, add callouts to pictures, draw flow charts, edit vector and line drawings and convert images from one format to another.
8. Do work estimates
Have at least some idea of how long it takes you to complete a task from start to finish. This takes some practice but has not just professional but also personal payoffs. Bonus points if you're correct to within 10%.
9. Ask stupid questions
You can't be afraid to sound like a total newbie in front of SMEs. Especially in more arcane business areas this is frequently the case, and it's totally okay! If you knew the programmer's job, then that would be your profession, not tech writing. Know your strengths and don't be afraid to show your weaknesses.
It's a lot less embarrassing to ask a question up front than it is to submit a completely clueless first (or second, or final) draft!
Also, at the end of the day, you are not responsible for the technical accuracy of your docs, the SMEs are.
10. Use Google (+ other info resources)
Know how to phrase searches effectively and how to find the needle of information in the haystack of search results. Know how to evaluate the quality of sites from how they show up in the results. Know where to find additional information... and when to stop searching and start thinking and writing.
+ Writing
Communicate easily in writing, write texts at the drop of a hat in different registers for different audiences. Be able to adjust the tone, difficulty level, viewpoint etc. of any text, not just your own. Write all the friggin' time just because it's what you do.
This is going to sound corny, but you have to believe that what you're doing is important and meaningful. You can't just do it as a job, to pay the bills. Not for long. It will make you miserable, then crazy.
ReplyDeleteYou have to love it. You can be good at the job, technically, and still hate it, and you'll fail. But if you love the work, you can be crappy at all these technical aspects and you'll keep coming back to it and eventually you'll get there. It's the old line about finding something you love, even if you're bad at it, and doing it no matter what.
http://24.media.tumblr.com/ea73cf582c0e5a4dbe75b48c8f355bfb/tumblr_mz8xekgZgc1tpclkuo1_500.jpg
Also, I put an extra space in one of the paragraphs I just wrote. If that's not driving you batshit insane, you don't have what it takes to do this job.
I think the blog automatically removed my extra space, which sort of ruins the joke ... but go ahead and keep looking for it anyway.
DeleteChucky, if I didn't know so many people who just drifted into this line of work and couldn't summon the energy to leave, _then_ I'd agree with you.
ReplyDeleteAnyway, this is just my list of what I expect to find when I meet a colleague who's been in the field for more than one year. It's the sort of thing you pick up, if you have half an ounce of interest in what you (we) do.
To change the subject, I forgot something from the list: the ability to solicit information from real live SMEs, and the ability to take feedback for your writing without it being a big deal. The first differentiates between the mediocre and the successful tech writer. The second one differentiates between someone who can stay sane doing this, and someone who can't.
> Chucky, if I didn't know so many people who just
Delete> drifted into this line of work and couldn't summon
> the energy to leave, _then_ I'd agree with you.
Fair. But I don't want to work with those people and I think even if they master all the skills on your list, they're still going to be shitty technical writers.
On the other hand, a surprising number of people will cultivate this very attitude ("this is a horrible monkey-on-a-typewriter job and I just got stuck doing it") when they don't really believe it themselves. They're doing it because they love it. They just don't have the self-confidence to shout it out.
> Anyway, this is just my list of what I expect to
> find when I meet a colleague who's been in the
> field for more than one year.
ORLY? Then let me add another one for you: the ability to control topic drift.
I see you're well on top of it. *wink*
> It's the sort of thing you pick up, if you have
> half an ounce of interest in what you (we) do.
Fair. I'm merely accentuating the importance (to me) of that half-ounce.
As to topic drift, I _could_ have posted separate replies to address separate issues and/or accommodate different points I wanted to make, but that would have been useless expenditure of effort because you were able to comprehend me just fine ;)
DeleteAll valid points above, although I think emphasis will shift based on personal taste.
ReplyDeleteI would extend point 9 and something stchucky said:
To thrive, you need to a passion to learn new things be it through asking questions, Google, or looking at the product.
Nick...
This is one of the great things about writing, you get paid to learn things.
"This is one of the great things about writing, you get paid to learn things." - AMEN. I actually went through my first year as a tech writer constantly thinking: "... and they PAY me to do this?"
Delete