Number One Issue for Technical Writers Today: Keeping Pace with Rapidly Evolving Technology
March 1st, 2007 | Posted in blog 13 Comments »
From our virtual chat, we decided that the most significant issue technical communicators face today is keeping pace with rapidly evolving technology. Here are a few quotes from the chat:
- “For me it’s keeping up with the right technology and fighting to increase productivity without making our jobs horrid.”
- “I have trouble keeping up with the rapid pace of innovation in the IT world and the many ways to deliver content.”
- “Part of the problem about keeping pace with technology is that we often work under tight deadlines. B. mentioned the budget cuts and overtime. So at the end of the day, to learn new tools and technology, it’s often on your own time.”
- “I agree and I’m willing to learn about new tools and technology. The question is, where to start, what’s the right thing to get into? What do I recommend that the company invest in?”
- “Another problem with keeping pace with technology is the sheer variety of languages, systems, tools, concepts, etc. There is so much to know. One can’t know it all. But I think we have to be savvy enough to learn what we need to know at the moment we need it.”
- “The most significant challenges and changes have been the budgets have been slashed for projects/training/user communication in general. No time/budget/interest in keeping me trained in my field. That is my biggest challenge right now. Years ago, I was regularly sent by FPC to conferences/semi nars. Now it’s a rare event.”
I’ve been thinking about this question for a long time — what’s the biggest issue for technical communicators today. I think the chat brought it out perfectly. There’s a lot of technical knowledge to master, and the technologies are only expanding. The number of tools available has exploded. And yet technical communicators are often overworked, with multiple projects, tight deadlines, and little budgetary privilege to take technical courses and keep up.
I asked what tools the group would like to learn. The responses: Microsoft Project, AuthorIT, FrameMaker, HTML/XML, javascript to enable user interactions with content, DITA, XML, and wikis. But many aren’t exactly sure what they should learn. Many still use RoboHelp and Word.
One participant commented, “In the end I think my best tool has been my analytical intellect and my ability to perform controlled tests.”
Coincidentally, today I also listened to the DMN Communications podcast on “Becoming a Technical Tech Writer.” Aaron and Scott explained that you have to know a lot of different programs, languages, and technologies to be a competent technical writer. And then they named quite a few technologies: Unix, Perl, XML, command-line, C++, DITA, PHP, and so on. I was pretty impressed. I didn’t know they were so tech savvy, and it actually depressed me a bit because I wasn’t as familiar with it all.
But they didn’t mention .Net, and most of the programs at my work use the .NET. I may never need to know Unix to perform my job. In the end, it’s not as if you just learn several languages or tools and you’re all set. You have to be quick and intelligent enough to teach yourself the language or program that you’re currently documenting. You have to be tech-savvy enough to learn quickly, to pick it up whatever it may be. What do you need to know? Learn that. Teach yourself tech. That is the real skill, because the technologies are constantly changing, and what you may need to know today will be outdated tomorrow. One project may require knowledge of X, and the next knowledge of Y. It’s the ability to learn — and more importantly the love of learning — that will make you excel in the field of technical writing.
Sponsors
Tags: 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.
4010 Subscribers
There’s a lot in what you say,... (
Mark Baker (5)
DiSc (3)
Jen (3)
Richard Hamilton (3)
Jenny (2)
Sarah Maddox (2)
Sarah O'Keefe (2)
Aneesha (1)
Barrie Byron (1)
Catherine Crane (1)
I’d Rather Be Writing help a virtual chat with several technical writers last week. They identified the main issue facing writers right now as keeping up with rapidly evolving technology
Thanks for the link to that podcast; I will check it out.
I agree with your recommendation to learn what you “need”. Because new technology is so varied and fast-moving, I can’t afford to learn things “on spec”. I keep up with trends so that I know what’s out there, and so I that can have an idea of what technology might be applicable to a particular problem. But learning a particular technology just for the sake of learning it may be wasted effort if I never use that technology on a project.
I realize this may sound like I don’t value “love of learning” — I do. But try to find a way or a reason to apply what you’re learning, even if it’s tracking your kid’s Little League team’s records. And if your company uses .Net, don’t bother learning Java right now; learning .Net makes much more sense.
Tom,
Great post. Something that you (and Aaron and I) didn’t go into too much detail about was the level of knowledge that you need. With some technologies, having enough knowledge to be dangerous is enough — you have a grasp of a technology, and can intelligently ask developers questions about it and understand the answers. With others, you’ll need a more in-depth knowledge.
There’s also a lot of what I call “situational knowledge” — things you know for the duration of a project or release. For example, a project that I just worked on required me to learn quite a bit about logical partitions on AIX. I think I did a pretty good job of explaining how the software I was documenting interacted with LPARs. But I’m sure that in six months (or less) I’ll have forgotten most of that.
I think, though, that the previous poster (Janet) said it very well: “I keep up with trends so that I know what’s out there, and so I that can have an idea of what technology might be applicable to a particular problem.”
Scott
Scott and Janet,
Thanks for your comments on my post. Scott, your podcast was excellent and I should have praised it more. I have met so many technical writers that lack basic technical knowledge and skills that I call them “untechnical” writers.
I agree that knowledge must be relevant and necessary to a task at hand. You know, I often want to delve more into the technical details of the applications I document, but a lot of times knowledge of the code isn’t necessary to write the user guide. I can see how some situations would totally require that knowledge, but there is a softer side of tech writing (for example, right now I’m documenting Microsoft CRM) that just requires understanding of how the program works.
I would really like to develop a knowledge of PHP so I can hack WordPress into a help authoring system. One day I will …
Keep up the great podcasts. Scott’s voice was a little soft last time, but I like the focus of your show.
I just saw this new information learning site from Microsoft.
http://msdn.microsoft.com/vstudio/express/beginner/
Tom,
Have you checked out the PHP Visual QuickStart book from Peachpit Press? It’s quite good. Heck, a few PHP developers I’ve worked with have recommended it.
Actually, I’m kind of partial to the Visual QuickStart series. And to a number of “Learning” books from O’Reilly & Associates.
Scott
Thanks for the recommendation, Scott. I’ll check it out.
[...] Tom’s I’d Rather Be Writing [...]
Hi tom! nice post:-)
I’m actually an entry level technical writer here in the Philippines, I’m an IT graduate and finding a career after graduation was really very hard for me before. Last year while at work my supervisor noticed that I have some talent in writing and since I’m an IT graduate he endorsed me to be a writer.
I agree that in order to be a good technical writer you need to learn a lot of tehnologies and you must be very updated, but now I can’t focus myself of what am I going to learn first.
Can you give me some advice?thanx and more power:-)
What to learn first? Probably styles in Word. Then an online help authoring tool like Flare. Then a graphics program, like Paint Shop Pro or SnagIt. And keep up with the podcasts on http://www.techwritervoices.com.
If you really want to get techie, learn XSLT.
Just kidding on that last one.
[...] articles, books, and blogs. Listen to podcasts. If possible, attend conferences. You can find a great set of links to [...]
[...] in technology and you will be surprised at the ideas and experiences the discussion generates. This third tip arose from the weekend discussions. The technology writers blog: I’d Rather [...]
Thanks for your post. It has given me a lot to consider. Thanks again!