How to avoid becoming extinct in your technical writing career
I ran across a couple of must-read articles in Tech Crunch this week. The first is titled Your experience is probably worth a lot less than you think by Jon Evans.
Evans argues that technology is changing so rapidly, the knowledge and approaches you used a decade ago are now pretty much obsolete. As a result, when you emphasize your experience as a selling point for your skills, it doesn’t mean much. Evans writes:
Do you work in software? Do you have more than a decade of experience? You do? I’m sorry to hear that. That means there’s a strong possibility that much of what you know is already obsolete. Worse yet, there’s a good chance that you’re set in anachronistic ways, hidebound with habits which are now considered harmful. If you think your experience is automatically valuable, I warn you: think again.
A decade ago, I was single sourcing content using Robohelp, outputting the content to Microsoft Word and running a kludge of macros to fix the formatting so we could also print a PDF. We often printed out copies of quick start guides and stapled them together before distributing them to financial analysts. (Yes, using an actual stapler!)
On my first week on the job, a senior technical writer explained that I needed to provide detailed steps to users for even the simplest tasks, such as how to print something. Now that kind of approach is looked down on as providing obvious documentation that no one needs.
The de facto assumption for most of the twentieth century was that experience was assumed high-value unless proven otherwise. In technology, in software, this is no longer the case. Increasingly, instead, your experience beyond a certain point — say, 5-10 years, depending on many factors — is assumed low-value unless proven otherwise.
The devaluation of experience means all of those bios that tech writers have that begin, “John such and such has more than 20 years of experience….” might be a little hollow.
What’s the solution? Evans says the trick to avoiding extinction is to keep learning:
The most important skill, one that truly doesn’t get old, is the meta-skill of constantly learning new things … and that meta-skill can rust and wither away, too, if it languishes unused.
On the heels of Evans’ article is another TechCrunch titled In a knowledge economy corporate learning is necessary to survive by Karl Mehta.
Mehta makes a similar argument as Evans but applies it to the corporation. Corporations must help their employees keep up with the rapid pace of technology to avoid stagnating with old, outdated processes and products. Mehta writes:
The education that the workforce received was designed in the previous industrial age: front-loaded for first 20 years, and expected to apply to their jobs for the next 40 to 50 years. Today, we are in the knowledge economy, and there is new knowledge we are required to learn and apply daily.
In other words, technology professions differ from others that have a long learning ramp followed by many years of implementation. (Think medicine, for example.) With technology, you don’t just sink in 4+ years learning your trade and then go to work for the next 20 years. Because tech is evolving at such a rapid rate, your learning must be continual.
In fact, Mehta cites a study that predicts most Fortune 500 companies will be extinct in a decade:
A study by Washington University predicts that 40% of Fortune 500 companies on the S&P 500 today will not exist ten years from now.
The solution Mehta proposes is a similar one as Evans: continuous learning. Mehta says:
AT&T recently told its employees to update their skills in five to ten hours weekly of online learning or they “will obsolete themselves with the technology.”
How do you implement continuous learning in your career? My company recently provided access and enrollment to Udacy’s Nanodegree programs, among other learning resources (such as Big Ranch Nerd). I’m starting an Android Developer Nanodegree program, which is co-created by Google.
A “nanodegree” is a degree that has a granular focus on a specific skill, and takes about 9-12 months to complete. The course instructors recommend that you devote a specific block each day to working on the degree (about 8-10 hours a week). I find that dedicating the first hour of my day to the course is about the only way I can fit in in. Then I try to follow up with another hour before bed.
Why Android? It’s relevant to the products I document. Amazon’s operating system, called Fire OS, uses Android as its base. There are some differences, mainly with the incompatibility of Google Services with Amazon Services in the Appstore, but the core Android code is the same (and tries to maintain parity so that developers don’t have to code their apps for yet another platform).
I like knowing that the time I spend learning will be for a domain that has widespread applicability and isn’t just a niche oddball technology product that is so specialized and unique, the knowledge gleaned would have little use elsewhere.
Before starting this course, I made it 50% of the way through Android Development for Beginners. These Udacity are some of the best courses online I’ve ever seen. The pacing was just right, and the instructors are fun to listen to and learn from. Udacity knows how to put courses together. When you’re matched up with the right level course, the instruction and activities can be incredibly helpful.
Coding for Writers
Speaking of courses on coding, Peter Gruenbaum, who created several courses on API Technical Writing, recently released a new course titled Coding for Writers 1: Basic Programming. Here’s part of the course description:
Are you a writer who wants to learn how to code? There aren’t many people who can both code and write well, so if you can do both, you will find there many exciting, highly-paid opportunities in the technology industry. This course teaches basic programming to writers, combining learning about coding with learning to write about coding.
The course is geared toward writers who are beginning to learn code. If this interests you, use coupon code IDRATHER to get a discount.
Another Resource: Safari Books Online
Another resource I use is Safari Books Online. I love Safari Books because there are generally multiple resources (both books and video) addressing the same subject, and you can read from specific chapters or videos without taking in the entire resource.
My Android Nanodegree program says students should have at least one year of Java programming experience prior to starting the course. My working knowledge of Java seems to be enough for most cases so far, but sometimes I need to refresh my memory or learn some things.
For example, recently the Udacity trainer said to add an ArrayList in a Java class, and didn’t explain much about how to do it. Unfamiliar with ArrayLists, I turned to Safari to learn more about the ArrayList and then returned back to Udacity.
Safari Books is pricey, but you can usually access this resource free through your local library’s online portal or through a corporate subscription.
Although continual learning is a requirement to avoid extinction in our field, fortunately there are abundant resources to stay current online.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.