I have gotten more and more interested in technical writing and I have a job interview over Skype coming up next week. What I have understood is that, apart from creating documentation, a lot of time is spent working on understanding the product in depth and also staying close to the development process.
I like to hear what other campers think. If you are a technical writer or cooperated with technical writers, what do you see as the pros and cons of this profession?
I had a class in college and did a little technical writing professionally.
Are you the kind of guy who is exacting in detail? Can you take complex concepts and boil them down? Can you logically deconstruct an explanation to remove any ambiguity and make sure there is a logical sequence of ideas? Can you quickly absorb complex technical ideas, even in fields you haven’t studied? Do you have a firm grasp of the rules of English grammar? Have you read the Chicago Manual of Style or Elements of Style or any of the other books of that ilk? Do you know the standards of document formatting?
These are some things that I think about when I think about technical writing, based on my limited experience and from TWs with whom I’ve worked.
Have you done any before?
It’s important and difficult and underappreciated. You may or may not work closely with the development process (in my experience, not). You probably would work more closely with stakeholders than with engineers. You may get a good understanding of the interface you’re writing about (whether it’s a GUI, an API, or hardware components) but don’t need to know how things work under the covers.
My wife worked as tech writer at Intuit TurboTax software many decades ago, writing the help files and line-by-line prompts. In her capacity, she worked closely with both the tax experts/business experts and the developers. She wrote the documentation using XML files, which are submitted back to devs for further processing into the final software product. In this case, the end users are the general public so the documentation/instructions must be clear/easy to understand – making something complex, easy to understand. A liitle bit of QA/testing too to make sure the devs incorporated the right help file/prompts in the right location/fields.
Thanks for all the good replies on this thread. I really enjoy writing and making the complex understandable, and I have seen a style guide before. Being a technical writer is still a profession of its own and it requires much more than being good at writing in a general sense.
@ksjazzguitar I’ve taught languages and also done freelance translation work. I would say I am cognizant of grammar and language topics rather than an expert. An expert might know things of the top of their head. I am more someone who notice what is important and know what to ask for. This comes from planning lessons which means having to plan for teaching a particular grammar point lesson by lesson. Standards of document formatting is another story though, I am quite at sea there. If I tell you that I would happy to do all my writing in Markdown and never open up Microsoft Word again it probably reveals my ignorance. I will look into standards of document formatting before of the interview so thanks for the tip. If you know a good place for me to start please let me know.
@ArielLeslie .Thanks for your reply. Those three words capture Knowing the interface but not necessarily what goes on under the covers is a good point. The thing is, I am very much motivated by understanding how the code works. That is why I’m learning at FCC in the first place.
@owel That is a good description of the day to day work, thanks.You also mention up documenting in XML. I wonder if XML is still used. I will try to learn more about the whole documentation process ahead of the interview.
I think so. I remember Robohelp being much in use back then (mid-90s). It’s still around, and now owned by Adobe.
I guess I would run out and by a copy of “Technical Writing for Dummies” or something similar.
But it always makes me nervous when people are applying for a job in a certain field and have to ask what that field is and what it entails.
But the flip side of that coin is that TW is one of those jobs that often people study at the university but is also sometimes a job that people kind of fall into. Sometimes a company just needs a TW and says, “Hey, Carl, we need someone to write up these specs. You write well, why don’t you give it a go.” And Carl becomes the TW guy and gradually builds up skill and knowledge.
When I talked about “standards of document formatting” I don’t mean that there is one standard format, but that there are standard ideas. Maybe “principles” would have been a better word. Things like knowing what margins and gutters are, how tabbing works, what a hanging line is, what drop case is, how different fonts are used for different items, what should be italicized, what should be bold, how to deal with orphans. Having delved deep itno a good word processor would expose these things. Working with a DTP would be even better.
But it also depends on what type of TW you’re doing. The little that I did was for documents. Owel mentions another side of it, writing for the internet, which can be a very different world. Yes, I would expect they use XML (or something similar) so the software can easily load your comments. The comments can changed without having to change the code.
@owel @ksjazzguitar Thanks again for the tips. I will have a refresher in document creation and terminology. I still keep my hopes up for Markdown as the text format. Right now I am halfway trough the Write The Docs Portland 2017 playlist to get a better idea of the technical writing domain.
And it’s entirely possible that markdown will be the format they use, depending on what they use it for and who the audience is.