Rahel Bailie had received this article in her email and shared it in Facebook, and I’m glad she did. I have to say, I don’t agree with the author’s viewpoint, although I understand it.
Let me start with this: TECHNICAL WRITING IS NOT DEAD.
Since I’m still a relative newbie to the industry, my response to this author is that this is why the industry is known as “technical communication”, not only “technical writing”. The reason that these combination jobs are happening is quite simple: employers are cheap. It’s really nothing else. Yes, there are people out there that are talented enough to be both technical writers AND analysts, programmers, instructional designers, etc. But what this shift really involves is a shift in how business is done–a necessity for all technical writers, no matter who they are. They have to have a broader understanding of other aspects of the IT industry to survive, no matter what industry their company is. Let me explain.
Learning these other skills was inevitable. Once the digital age started, there was no going back. Writing documentation for software and hardware became normal. As time as gone on, social media and mobile have upped the ante for digital documentation, because digital documentation is practically universal now. When universities have related programs, it’s not degrees in technical writing alone, but rather it’s technical communication, because we are taught about graphic design, UX/UI practices, social media, content strategy, and more. We are taught that now, whether it’s through formal education or through working experiences. This is the “new normal”. But technical writing is not dead, and having it as a skill is very advantageous.
My husband is a programmer/web developer. English is not even his first language, even though he’s has about 98% native fluency in American English. He can write better than most people born in this country. HOWEVER, he’s the first to say that while he can write a good sentence, and he can recognize a bad one, he’s not really the best person to write user-friendly text or content. He’s not the best content editor out there. He’s a programmer, so that’s what he does and does best. He leaves the writing part to others to provide the best solutions possible.
At one position I was at, I was working with a fellow who felt so proud that he was getting a degree in programming, so learning the company’s CMS system was going to be great so that he could help a team create web pages. When I received the initial content that needed to be added, it was one of the worst things I had ever seen. Poor grammar, text that didn’t make sense, and images that looked like a clown vomitted and didn’t represent the group well at all. A technical writer understands these things.
Right now, I’m in a position as a UX technical writer. It’s my first real writing position other than blogging. I work with UX designers and graphics designers who are very good at .what they do. While they do have a good grasp of user-friendly language, the other tech writer and I have been tasked with cleaning up the content of the wireframes so that things are consistent, clear, and cogent. The designers don’t have that mentality, and so they add–or sometimes don’t include enough–text that will enhance their customer’s experience.
So, while this author makes a great point that you can’t limit yourself to writing solely, technical writing is NOT dead, but enhanced. After all, it’s not the Society for Technical Writing that many of us belong to, but rather the Society for Technical COMMUNICATION. Technical communication is a much bigger umbrella that covers more than technical writing alone, but it is the foundation of it all. Technical communication in the 21st century is about being a multi-tasker and having multiple disciplines. It makes you a better candidate for employment, and it makes you a better employee. Even in the few weeks that I’ve been at my current position as a UX tech writer, I’ve pointed out things to the UX designers that they hadn’t thought about before, because I had training in UX/UI. They also saw that as a blogger and content strategist, I knew how to write and what would be best for the user reading the content.
It all works in the end, but this is why all of us need to think of ourselves as technical communicators. We are more than technical writing, but technical writing is far from dead. We have a skill that the analysts, instructional designers, and programmers wish they had. While we should enhance and broaden our skills, we should not think of ourselves as programmers or analysts who can write, because most can’t. We are writers that can program and analyze–that’s much more valuable.
What do you think? Include your comments below.
4 thoughts on “Surviving the Dying Career of Technical Writing :: UXmatters”
Danielle, I agree with you — and with what I think the authors of the original article were trying to say. Technical writing as we knew it 20 or 30 years ago is dead. But those of us who’ve evolved with the profession — who’ve developed expertise in programming, UX, etc. — are well positioned to succeed in the future.
Here’s a tidbit for you: The Society for Technical Communication used to be known as the Society for Technical Writers and Editors. The name changed, I think, around 1971. Even back then they recognized that the word writer was inadequate to describe what we do.
Yes, I figured that the STC’s name had evolved somewhere along the line. But as long as I’ve been a technical communicator (which, if we say it started when I started grad school) is about 6 years now, it always embraced multiple disciplines. I don’t label myself as a technical writer most of the time, but rather as a technical communicator for the purpose of letting others know that there is more to me than just writing and editing. Now, if the rest of the working world would get that hint about us…
I didn’t like with the tone of the article. It had too many generalisations and no attempt to introduce any evidence, even anecdotal evidence, to back anything up. For example, it mentioned “a recent survey” as a justification for one assertion but didn’t provide a link or a reference to the source. The only source mentioned in their references was a five-year-old personal blog contribution, which was not really relevant to the article. If you can’t support your assertions with evidence it’s just opinion, so why should I agree?
Thanks for the comment, David! Yes, I agree, the tone is what hit me first. It just sounded so…smarmy. I can’t think of a better word for it (not that I’m sure that “smarmy” is a word, but go for the connotation of it…). And you are right–there was no real data to back it up. I feel that the other problem with the article was that while a problem was presented, no suggestions of solutions were provided either. That bothered me as well.