14 Widespread Myths about Technical Writing
June 26th, 2008 | Posted in blog 35 Comments »
Jefferson McClure added a thought-provoking article link on WriterRiver.com titled “Myths of Technical Writing.” The article is by Bob Doyle and appears on the dita.xml.org wiki site here. In the article, Doyle and other wiki contributors mention 4 myths about technical writing:
- The GlueText Myth
- The Stem Sentences Myth
- The Front-Matter Page-Numbering Myth
- The Callouts on Graphics Myth
You’ll have to read the original for the details. The debunking of these myths is supposed to help you embrace a structured authoring methodology like DITA. The myths are genuinely insightful, and it got me thinking about myths in a larger sense.
In part, I’m reflecting on myths because I was recently invited to speak to students at a professional writing conference at BYU Idaho in the fall with the topic, “Three Myths About Technical Writers.”
Apparently, many students pursing English degrees assume technical writers have “sold out.” They think technical writing is a “fallback” career. It’s something you can do if you’re starving and don’t have any other options. Oh, the financial naivete and idealism …
I’m not sure what will convince people immersed in Charles Dickens and Edgar Allen Poe and Chaucer and Emily Dickinson, who are writing about deconstructionism and feminism and the intersection of Shakespearian influences on postmodern authors, etc., that technical writing is more than just “press this button here to program your VCR…”
It will be a challenge, but one worth taking. When I was a student at BYU, I held these same biases against technical writing. I acquired the myths from one presentation by a teacher who represented the English faculty on technical writing. In a nutshell, compared to the other English professors, she was the most boring of any I’ve ever met — by a long shot. She talked about formatting phone books. I whispered a silent vow to myself that I would never, never become like her. While she spoke of layout and design for banal texts, other professors ignited us with literary ideas.
I now have a personal vow to make technical writing look like one of the most appealing careers one could possibly pursue.
In addition to myths about technical writing as a sellout and fallback career, I can think of at least 10 other commonly held myths surrounding the field of technical communication. I offer them below.
1. Technical writers spend most of their time writing.
Totally untrue. Most tech writers spend about 10% of their time writing. The rest of their time they spend learning applications, noting bugs, providing usability feedback, structuring their content, setting up styles for their help files, troubleshooting their tools, strategizing help deliverables, training new users, formatting and laying out their content, updating existing content, meeting with project team members, and occasionally playing ping pong.
2. You can’t get a job in technical writing unless you have technical writing samples; but you won’t have samples until you have a job in technical writing.
Don’t believe this for an instant. You’re surrounded by technology — your iPod, computer, DVD player, microwave, cell phone, BlackBerry, and everything else. Download a trial version of some help authoring tool, or even just open up Microsoft Word. Write instructions for something. Find an open source application with poor instructions and rewrite them. You don’t have to create an entire user manual. Just give your potential employer some evidence of your capability.
3. A technical writer who has years of experience is more knowledgeable than one with fewer years of experience.
This myth is turning into my pet peeve. How many bios have you seen that begin, “Joe has 15 years of experience …” or “Kate has over 20 years of experience as a technical writer….” Experience means nothing unless learning is taking place. I can go to my same job for 15 years, do the exact same tasks, use the exact same tools, never taking any creative risks or moving into new territory, just doing what I’m told, or what I’ve read, for my entire life. The pace of learning can be compressed into a very short time period, or it can drawn out over a life time. The time (years of experience) does not matter as much as the learning that takes place. (See this related post, MySQL CEO Says, “It is dangerous to hire someone with too much experience.”)
4. The tools you know are more important than your industry knowledge.
Many job ads say you have to know RoboHelp, Photoshop, CSS, HTML, Javascript, C Sharp, InDesign, Dreamweaver, DITA, XML, XHTML, and so on. But really, if you have strong domain knowledge about an industry, that knowledge can be a lot more powerful than a specific tool. For example, if you work in the financial industry, a Series 7 license (which allows you to communicate with investors) is a lot more important than RoboHelp. It can take months of study to get your Series 7, and only a few weeks to pick up a tool. (See this related post, Doug Davis on the Job Side of Technical Writing — Location, Industry Experience, and Salary.”)
5. Be careful about having a blog, because all employers google you and will find it.
When I hear this, I cringe. The discussion always comes up among non-bloggers who think blogs are a wart you need to hide. Sure if you have an embarrassing MySpace page where you mix profanity with vulgarity and other shady content, that’s a site you need to obliterate. But a professional blog demonstrating your knowledge of technical communication can be a powerful tool for getting an edge on other job candidates. It can also serve as a tool for professional development and keep you enthusiastic about your career.
6. Technical writing academics are disconnected with the profession and only have a tenuous idea about the actual practice of technical writing.
Many academics started out as technical writers and worked for years doing the same things we did. Are we practitioners so vain that we think the industry is rapidly changing from year to year, so much so that intelligent people who spend years immersed in texts, studies, journals, and experiments have no idea what our jobs involve? Academics may not be totally fluent with the latest tools, but that doesn’t mean they’re disconnected with technical writing practices and challenges. (See this related post, “Reflections on Allison Reynold’s Talk on Job Skills for the Workplace.”)
7. You can’t have voice or style in technical writing. It has to be objective. And the fewer contractions, the better.
All writing has voice. You don’t have to remove all sense of humanity from your writing. A writer who uses contractions, moves toward conversational style, and truly has voice will provide a better experience for the frustrated user who seeks human help rather than cold robotic formalese. The talk that changed me forever was this keynote by Kathy Sierra at SXSW, where she explains the need for human qualities in help material when users, in desperate frustration, finally click the help button. If you want to sound like a robot, eliminate all contractions from your writing. What tone do you think users respond better to?
8. Technical writers aren’t allowed to contact users directly. They should get their information through the product manager, customer support, and marketing.
Here we see yet another wrong idea that will only put up roadblocks for worthwhile help. Joe Sokohl clarified this principle at Doc Train West 2008, calling it the Kobayashi Maru principle (a reference from Star Trek). He says you have to throw aside the idea that you can’t contact users. Without this contact and the information you can gather from users, you’re hopelessly doomed to write instructional material they don’t want.
9. You can single source your material into all the formats your audience needs, if you just learn the right tool or technology.
When you learn to structure your content with DITA, you can magically transform all your content into every format your users need. NOT. The type of instructions you write for a one page quick reference guide varies from the kind of style you need for an iPhone or for a long manual. While I agree that you can single source online help to a software manual, the idea gets taken too far. (See this related post by Gordon McLean, “DITA Is Not the Answer.”)
10. You have to be quite tech-savvy to be a good technical writer.
Actually, when you become so tech savvy that you can’t imagine users not understanding how to disable a popup blocker or not knowing how to do a simple task, when you are stunned at users who double-click when they should single-click, or who single-click when they should double-click, at this point, you lose some ability to write for the lowest common denominator. It’s not such a bad thing if you’re technically challenged. So are most of your users! You’ll be on a level playing field and will probably write a help manual that actually speaks their language. (See this related post, “The Curse of Knowledge — The More You Know, the Worse You Become at Communicating that Knowledge.”)
Sponsors
Tags: false concepts, myths, Technical Writing
If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.
Both comments and pings are currently closed.
Mark Baker (5)
DiSc (3)
Jen (3)
Neal (3)
Richard Hamilton (3)
Ellis Pratt (2)
Jenny (2)
Sarah Maddox (2)
Sarah O'Keefe (2)
Stefan Kleineiken... (2)
In addition to adding Google Reader Shared Items to the sidebar, I’m going to post links to a few good articles, by topic, every so often.14 Widespread Myths about Technical WritingPreparing for the Technical Writing Profession, Part 1 Preparing for the Technical Writing Profession, Part 2 Developing Knowledge Base Articles Reading Lists for Technical Writing Trends, Tools, Technologies in Online Documentation
I’m struggling to think of anything to add to this Tom, excellent post and right in every way I can think.
I’m sure some will knock some of your suggestions but it’s about time some technical writers woke up and realised what was going on. If you aren’t onboard with these kind of things then you will be left behind (if you aren’t already).
Gordons last blog post..Your publishing model is broken
Excellent article. I have to disagree about tools though. While, in an ideal world, industry knowledge counts for more. Most of the calls I get from recruiters are due to my knowledge of specific tools.
Thanks to my current job at a credit card processing software firm, I now have reasonably good knowledge of the credit world (especially on the back end), but my bet is the next job I get will focus on something completely different. You can be sure I’ll be using some of the same tools though.
John Hewitts last blog post..Six Suggestions for Sustainable Writing: Inspiration from Frank Herbert’s Dune
[...] Your page is on StumbleUpon [...]
Tom,
While I’m not sure it’s really necessary to cite the author of a cite, it was actually me, and not Anne Gentle, that posted the link on WriterRiver (which I absolutely LOVE, btw).
I don’t currently have a professional blog to share, but WriterRiver is definitely inspiring me to start one.
Thanks
[...] 14 Widespread Myths about Technical Writing: No, technical writers are not superheroes. No, technical writers do not control American Idol. Yes, technical writers are snappy dressers. [...]
Jefferson, sorry about that. I updated the post to be more accurate. I think your story was right above one from Anne, and I just confused the two. Thanks again for submitting this on WriterRiver.com.
John, I agree that recruiters are more bent on tools than industry knowledge, for the most part. However, I think they too are caught up in the tool myth. We know that most writers can learn a company’s tools in a relatively short time.
That said, I guess I only half believe this myth. Some of the more powerful tools can take a long time to master. For example, being able to open up an image in Photoshop and completely manipulate it is not a skill to underestimate. Or being able to customize a webhelp skin, or create a CSS file that makes your web design pop. These are skills that take a long time to learn.
Thanks for pointing this out.
The only thing I could think of to add to the list is that people think all Technical Writers are grammar experts. Depending on their background and education, their skills as editors can vary greatly. Having the ability to create solid documentation does not always mean that editing other people’s words will come very easily. Of course there are a myriad of books, style guides, and grammar usage guides to help, but one should not assume that every Technical Writer started their life as Undergrad English or Linguistics majors.
Furthermore, one should not assume that every talented writer/editor will have the aptitude for technical writing or creating documentation. Not everyone can easily adjust to writing for a very wide audience, and not everyone can describe technical processes in plain English with success.
Love that you debunked the myth that technical writing has to be objective and impersonal. The point of technical writing is that it’s supposed to be helpful to the user, whether it’s an end user or specifications for database changes. Most people don’t even read instructions anymore because they’re so bad that users don’t know half of what their products can do.
I write instructions for my mother-in-law to help her with her computer or digital TV remote. She’s over 80, isn’t dumb, but has no time to read bad instructions. There’s a reason the KISS and ____ for Dummies books are so popular; they boil down very technical information (in many cases) to make it easy for people to learn. Not sure why it’s so difficult to make that available for everything.
I’m not even a “technical” writer, but know good instructions when I see them.
Great list!
Number 3 is a variation of one I heard when I did teacher training oh so many years ago. It went something like this (some of it may have got lost in translation!): If you’ve been teaching for 20 years, did you teach the same thing each year for 20 years, or did you learn from each year of teaching and teach 20 different things over that 20 years?
Number 4 depends on the industry and the audience. There are some areas where domain knowledge is critical, and others where little or no domain knowledge can be A Good Thing (TM). If you’re writing about financial stuff to Mum and Dad investors, you may not need the level of financial industry experience that someone writing for high level investment and banking companies may need.
Rhondas last blog post..Outlook: Delay outbound mail
“It’s not such a bad thing if you’re technically challenged. So are most of your users!”
Come on Tom, this is malarky! I think at least a quarter of my users are MSEE/MSCS types. The reality is:
1)Complex product documentation requires that the TW understand the user-oriented fundamentals before being able to document the product. In the hardware, software, tools, etc marketplace there are a A LOT of complex products. By virtue we can’t go around telling technical writers that they don’t have to be technically savvy when a sizable portion of the market must respond to complex products.
2) Let’s say you’re fresh out of college, not too technical, and want to go into TWing. You work 10 years, leaning on your ability to relate to the non-technical user. But after a while, don’t you catch on to how software works, don’t you automatically turn on that pop up blocker? Would or should there be a way for the TW to remain as a Luddite? (this is rhetorical question)
I propose these ideas:
– There is TW work for people of all technical skill levels. We should be telling prospective TWs that they need to find the projects that suit them.
– More importantly, one of the key skills for TWs is the ability to always see a procedure as a list of its component steps. If we stress this skill, then we don’t have to worry about a TW becoming too experienced to document for the lowest common denominator.
I take offense to suggesting that TWs need not be technical. I think the profession as a whole should suggest that TWing encompasses a large range work. Despite the name, empathizing with the audience is in the top-5 skills a TW must have. This is the most broad way to frame it, and doesn’t exclude any side of the profession.
w0s last blog post..Firefox 3 adoption rate and the culture of the Internet
w0,
All right, all right. I may have overstated #10 a little. I do think a good tech writer does have to be somewhat tech savvy. You have to figure out how complicated software applications work without any instructional materials (because you’re writing the instructional materials).
And as you say, there are wide ranges of technical material, from books on programming in Visual Studio to guides on using Hotmail.
However, there is a curse that comes with knowledge (which I wrote about here). The curse of knowledge is that “when we know something, it becomes hard for us to imagine not knowing it.” This can work against us when writing instructional material.
For example, let’s say you’re creating video tutorials and the videos are somewhat large, so users need to adjust their screen resolution if the videos don’t fit on their screen. For people familiar with computers, adjusting screen resolution is nearly as easy as changing a channel on your TV. But do you think your Mom knows how to change her screen resolution? If you tell her to right-click her Desktop, will she realize what the “Desktop” is? Moreover, once she gets to the screen resolution tab, will she know what to do?
For the tech-savvy writer, it’s easy to say, “For optimal viewing size, adjust your screen resolution to 1024 X 768 or higher.” But for a tech writer who is not as tech savvy, he or she will more naturally realize that some users may not even know what screen resolution is, much less how to adjust it, and what a more optimal number would be.
A good tech writer should know the skill level of the user base and write at that level, sure. I’m just pointing out that we all write with a lot of assumptions and sometimes those assumptions can work against us.
But overall, yes, I think in choosing whether to be tech savvy or not, it works more in favor of the tech writer to have technical skills. Thanks for your comment.
This is probably just semantics…in one of the comments, you use the following example:
“For the tech-savvy writer, it’s easy to say, “For optimal viewing size, adjust your screen resolution to 1024 X 768 or higher.” But for a tech writer who is not as tech savvy, he or she will more naturally realize that some users may not even know what screen resolution is, much less how to adjust it, and what a more optimal number would be.”
I’m tech savvy, but I would only use the first example if my AUDIENCE was tech savvy. And it seems to me that a tech writer with less experience would find it easier to write “adjust your screen resolution” because a SME told them to, not understanding that not everyone knows what that means.
I don’t think their “tech-savviness” has anything to do with it. After all, once they learn how to set their screen resolution, they’re more tech savvy…but not necessarily a better writer.
It has to do with experience, which is discounted in myth #3
. A more experienced tech writer, tech savvy or not, would know to write for the audience, not themselves.
(Or maybe I’m just defensive because I’m one of your “pet peeves”, since my bio states that I have more than 25 years of experience
.)
Char James-Tannys last blog post..An Event Apart Boston 2008 ended today…
Char,
“And it seems to me that a tech writer with less experience would find it easier to write …”
I think we use the term “experience” loosely. What you mean in the above sentence is a tech writer with less “audience awareness” or a tech writer with “less skill.”
There are plenty of tech writers with a lot of experience who are still bad writers. This is why I dislike the term “experience” so much. Not only is it vague, it’s also a rhetorical fallacy (an appeal to authority).
For example, “John so and so has 45 years of experience as a technical writer. What he says must be true.”
Actually, no. There’s no argument behind that. Experience itself is not an indicator of ability.
As an analogy, look at basketball. I have 27 years of experience playing basketball. I still am not as good as someone who might only have 6-7 years of experience but who happens to be extremely athletic with sharp court sense and better depth of field. See what I mean?
Labron James (who plays for the Cavaliers) is 24. He probably only has 19 years of experience playing basketball. Does it make any sense for me to trumpet my 27 years of experience in contrast to his 19?
This article and the comments made me think deeply about the way my company describes the TW profile. And I am sure most companies look for the same qualities/qualifications in TWs – experience as a TW, expertise in specific doc tools, domain/tech knowledge – besides some generic skills. Does your post, Tom, mean most companies are wrong?
I think your points are true to a great extent, but not entirely. Experience should never mean the number of years spent doing a particular job, but it does in this practical world. This is true for all types of jobs and not particularly technical writing. Other measures of experience are more difficult and expensive to measure. It’s unfortunate that many deserving but inexperienced candidates are overlooked in this process.
I agree that the ability to use some specific doc tool is not an important skill. But companies spend a lot of money purchasing doc tools and training their staff to use them. Isn’t it natural that they want to recruit TWs who have experience in using the same tools? My experience is that the ability to learn tools quickly and easily is a rare skill, and I expect this in only one out of ten TWs. You are very intelligent Tom, but I have to work with less gifted writers in my team who can’t learn a new doc tool effectively in four months.
As for technical knowledge about the domain/product, it is crucial for TWs. You can’t write about what you don’t know. That doesn’t mean you need as much technical knowledge as one would need to develop the product. It only means you need as much technical knowledge as one would need to use the product to meet certain objectives. With products getting more and more complex, sometimes this means substantial technical knowledge. Now, is it wrong to expect TWs to be tech savvy? There is no “Yes” or “No”; the answer is “it depends”, and you know on what.
Having said all this, I am happy that you raised this topic. TWs are fighting with a lot of myths around the world, and the biggest and oldest of them is still alive: “technical writing is a necessary evil”.
Jefferson,
Your comments about being able to conceive of people who don’t know what you and I consider basic tasks are right on target. I have been teaching my 78 year old mother how to use her brand new vista machine: her first ever. She has been using something called a mailstation until now, and has NO concept of what “point and click” means or that you have to press enter after typing something into a form.
Working with her brings back memories of having everything disappear off my screen back when I first learned Word in 1994, and the “Eureka” moment, when after retyping the same document 6 times, I finally noticed the “little rectangles along the bottom of my screen” and discovered all 6 copies were alive an well: and that I could have gone to dinner 4 hours earlier!
I always try to take some new computer course every year, just so I keep that “slightly confused” feeling fresh in my mind for when its time to explain some new product or tool to everyone who considers me their geek. I think it help make me a better writer.
Very nice article.
ESS
[...] 14 Widespread Myths about Technical Writing An intriguing look at our profession, Tom challenges some of the myths about technical writing and comes up with some great responses. The comments are well worth a look as well. This kind of post always seems to attract attention as, by it’s nature, our profession can be very hard to nail down accurately as there as just too many variables. Tom’s approach is one of the best I’ve seen. [...]
Bibhu,
I really enjoyed reading your comment. Sorry for the slow response here (just getting around to blogging tonight). Your question, “Does your post mean that most companies are wrong?” is one that got me thinking.
In my post, I don’t say that domain knowledge isn’t important. I’m say that domain knowledge is more important than technical skills. But I’m generalizing here, and all jobs are different. For some jobs, technical skills might be more important; and for others, domain knowledge. It really just depends.
But part of the evidence for my assertion comes from research by Doug Davis. I linked to him in the post (see #4). Here’s an excerpt from his writing. He says industry experience is now the most significant factor an employer looks for.
If I were to name all the tools I know, it would include a long list: Photoshop, Dreamweaver, RoboHelp, SnagIt, Paint Shop Pro, WordPress, Captivate, Camtasia, Flare, Word, Filezilla, RSS, HTML, XML, InDesign, Skype, Levelator, Pamela for Skype, Audacity, Acrobat, Visio, SharePoint Designer, and probably a dozen others.
If you’re am employer looking at my resume, you should be less concerned with the specific tools that I know and more interested in the fact that I can learn a variety of tools. You might look more specifically at the domain knowledge I have for your company. Do I know anything about investing? Do I know anything about the structure and methodology of your business?
Product Managers get paid a lot more than technical writers, and yet they seem to lack the tool knowledge of developers. Instead, their knowledge is in the industry, in understanding users and their business process needs. They are problem solvers, not tool experts.
If I were a hiring manager, I would be less concerned with the specific tools the applicant knows and more concerned with other types of knowledge — knowledge of the business. of users, of interacting in a software development environment, and so on. Knowing the tools is a given. If a tech writer can’t figure out Flare after a couple of months, I can send him or her to a Flare bootcamp of some kind and quickly get him or her up to speed.
If employers are just looking for someone who knows a tool, I think they’re focused short-term, trying to complete a finite documentation project. Employers who look past tools are looking long term. Ideally, an employer should say, use whatever tool you need to get the job done.
I really like the myth you brought up at the end — “tech writing is a necessary evil.” I should totally add this to the list! How many times have interaction designers and other project members felt that tech writing is an apology for a bad UI? I don’t think any UI can be intuitive enough to never need a manual. Even the iPod and iPhone, some of the more intuitive applications, still have their confusing points (like how you authorize your music on a computer after the hard drive crashes, and so on).
Thanks again for commenting.
Esther,
Thanks for your comment. I think help authoring almost approaches philosophy in this aspect — trying to know the Other.
One of the best activities technical writers can do is watch a colleague totally unfamiliar with the application try to complete a series of tasks using the instructions you wrote. Every time I’ve ever done this, I’ve thought, dang, I need to go back and make that simpler, add more screenshots, give more explanation.
Good tech writers who have the time to do this can write for those on the other side of the tech divide. I’m not saying it’s not possible; only that for someone not as tech savvy, it may come easier.
By the way, I used the word “technically challenged.” This is an entirely relative term. I once worked with a network engineer who thought I was anything but a technical person because I didn’t understand the 7 layers of networking and how storage arrays and IP networks worked. “And you said you were technical,” he’d scoff every once in a while.
And then when he needed a graphic in Photoshop, or needed to use Word, it was like he was ice skating for the first time — falling down all over the place. That’s not my area of expertise, he would say.
wO says:
“There is TW work for people of all technical skill levels. We should be telling prospective TWs that they need to find the projects that suit them.”
Plu-leeze: when is the last time any of you ever saw the following in a TW job ad:
“Wanted: entry level TW only Word skills, will train.”??
NOBODY, but nobody advertises for anything less than “2 years experience.” I’d love to know how newbies these days are supposed to get it? If they are new & clueless, they don’t even know about open source projects, let alone have the ability to actually do such projects with out supervision.
Where I am, everything is: “we need it yesterday & there’s no time or budget to train, so we only take experienced writers. If we trained someone, they will just leave in 2 years anyway.”
If there is a market somewhere for new TW’s, I’d love to hear about it as I know several who need more experience, but no one in my area wants to take them on.
[...] his piece about myths of technical writing, Johnson comments: 1. Technical writers spend most of their time [...]
Great post! Especially the things about “Objective style” and “Single sourcing as the answer to everything” are just what I’ve been thinking about for a while.
How can you single source and keep a subjective style at the same time? This is what is really bothering me!
I don’t want us writers to become machines writing the same day after day (“Click here”, “Click there”). This will end up in bad documentation and bad user experience. But in the end you want also a documentation that is somewhat standardized so that you can reuse it and translate it at lower cost.
Has someone any ideas or approaches on how bringing these opposites together? Or aren’t they opposite anyway?
[...] Johnson 14 Widespread Myths about Technical Communication 26 June [...]
[...] Am I to conclude that the author leaves “pure” writing at home, and then goes to work? No wonder Tom Johnson works so hard to convince students that technical writing is a worthy career. [...]
im studying to become a technical writer and i would really appreciate some help. If anyone has any pointers they can give me i would really take it to heart. And maybe even chat with me and let me know how the technical writing world turns. Thank you
[...] 14 Widespread Myths about Technical Writing [...]
Hi Tom,
Struck by your article, I never considered “Technical Writing” as a career option. Tsk, tsk.
I earned two degrees all about communicating. While in ministry, I handily relied on my English BA and Master of Divinity, direct applications. Yet, series of unexpected turns landed me in business, specifically sales.
I’ve sold everything from square feet to software, never thinking I would ever see a career application for my degrees. My degrees helped me with analysis and presentation, but I’ve always put them at the end of my resume following a string of sales successes!
Now, after reading your advice, I’m thinking “Converge selling, which I do well, with the writing, analysis, and presentation skills directly into a technical writing career, for more than $40,000 a year, right?
Now, after reading, there is hope in business, yet! Maybe, I don’t have to have another degree! That WOULD BE great news, if true. Thanks.
[...] trying to placate my anxiety a bit, I stumbled upon this article: 14 Widespread Myths about Technical Writing. For the most part, I found it useful but not necessarily encouraging. Myth #2 was especially [...]
[...] 14 Widespread Myths about Technical Writing [...]
[...] Myths about tech writing [...]
[...] Myths about tech writing [...]
[...] Johnson from I’d Rather Be Writing wrote a post titled 14 Widespread Myths about Technical Writing. One of the myths also addressed the question about how much time technical writers spend writing [...]
The big banks and Wall Street took billions in bailout money from taxpayers and then turned it into huge profit. In an insider’s club report a veteran trader exposed the banks and showed how the big banks made a huge power grab that allowed them to grow unchecked.
GC report: Now I could understand why we never have the freedom to do what we want to do.It is sure the big banks dont want us to see this.
I think many of your points are valid and interesting. I couldn’t disagree more, however, with the general assertion that tech writers don’t need to be especially technical. By far the best-paying writer jobs are for those with significant technical background in IT/security, networking protocols and/or software development. Most especially APIs.
Also bear in mind that many lower-level jobs have been outsourced/offshored to India. This practice has hollowed out many of the job categories that TWs once used as springboards to move ahead in their career. The ONLY way I’ve been able to continue getting callbacks from recruiters and companies at all is because of my extensive technical knowledge in specific areas. There are far fewer jobs out there then there used to be. Lose your job for six months and see what happens!
Anyone who actually WANTS to go into this field really needs to be familiar with IPv4 and v6 and have some knowledge of one or two key scripting languages or a high-level language. The more knowledge, the better. Many TW jobs around these days require a CS degree or a minor. It’s unrealistic to assert otherwise.