Distilling 20 years of tech comm into eight words of advice
Last month marked my 20th year working in technical communication. (Please send all congratulatory pastries and chocolates to Scriptorium’s offices. Thank you!)
I could painstakingly document how incidents in my career have contributed to the new gray hairs sprouting on my head, but that seems a little overboard. Instead, I will summarize my experiences so far into one piece of advice for up-and-coming technical communicators:
Understand how markup languages separate content from formatting.
My first projects in 1990 required me to learn IBM’s BookMaster markup language. I typed BookMaster tags and text into a terminal connected to an IBM mainframe. There was no formatting shown on the terminal screen: just green text and tagging. To see formatted pages, I had to run a print job. That stark division of content and formatting served me well later in my career when I worked on structured authoring implementations based on Standard Generalized Markup Language (SGML) and Extensible Markup Language (XML). BookMaster had already shown me that formatting was applied later to content based on a markup language. The formatting and the outputs changed over time (PDF, help, knowledge base, and so on), but the principle of post-processing for formatting was the same.
My career up to this point hasn’t been all about markup languages. I’ve done a lot of writing and editing during the past 20 years. Considering that “communication” is the key component of a tech comm job, written and verbal communication skills are still important in the field. I know my writing skills helped me land my first job. But strong writing ability just isn’t enough anymore. (See Sarah O’Keefe’s excellent post on this topic.)
If I worked as a manager in charge of technical content, I would look for employees with experience in markup languages. Presented with the choice of hiring an excellent writer with no markup language experience or a good writer who has worked with a markup language, I probably would hire the latter. Even if my department wasn’t currently in a structured authoring environment, the prospective employee’s knowledge of markup languages would likely have practical (and possibly immediate) applications: working with HTML content, setting up a wiki, and even assisting in the evaluation of future XML-based authoring. From a bigger-picture point of view, skills in markup languages are often a good indicator that an employee knows how to apply technology to improve efficiency and lower costs. I’ll gladly take that sort of business savvy in a decent writer over an excellent writer who just writes.
Technical communication programs at colleges and universities really need to show students how profoundly markup languages have affected the process of creating technical content. Classes must explain the impact of markup languages on tech comm and help students develop skills in using markup languages to create content. I’m not going to advocate teaching a particular tool or XML editor; schools could use basic text editors as a starting point to demonstrate the separation of content and formatting. If a tech comm program does not help students understand markup languages, the program’s students aren’t getting useful, real-world information they can use in future jobs.
If you are new to the idea of markup languages and are wondering where to start, take a look at these free Scriptorium resources:
- Structured authoring and XML
- Managing implementation of structured authoring
- The state of structure in technical communication
Your career in tech comm will be better for it—and the profession as a whole will benefit from technical communicators who demonstrate they do a lot more than merely write.
I’m off to eat a 20th anniversary raspberry blueberry cream tart. I think I’ve earned it!