Interview with Thomas Albert

What is your definition of technical writing?

Technical writing "translates" the engineering jargon and functional data about a technology into task-oriented information about a product that the customer uses to perform a workflow on the job. This "translation" of functional data into task-oriented information typically involves:

  1. Acquiring an audience definition and a sense of customer use cases for the product.
  2. Investigating the product to gain awareness of the concepts it assumes and the tasks it supports.
  3. Drafting a write up that typically includes explanations, procedures, and illustrations of the use of the technology with visuals or code examples.
  4. Providing use-advocacy feedback about defects or possible enhancements to the product, which might include suggestions about the wording in the graphical user interface or changes to the naming of the application programming interface (API).
  5. Revising the draft as necessary.
  6. Maintaining the documentation as the product undergoes updates.

What is the Research Phase in technical writing?

Who is my audience? Is the end-user:
  • a developer who is customizing the product?
  • an administrator installing, configuring, or deploying the product?
  • an end-user, such as a marketing director, a scientist, or an insurance agent?

What is the audience's level of technical expertise?
What is the audience's usability expectations and documentation usage preferences?

What are the use cases? What specific tasks does the customer need to do? The documentation needs to support the most common and critical use cases.
How does the technology work? By hands-on experimentation, I learn in detail the steps I need to document. Often, I discover issues that I can report to the team's bug database.

What would you do on the first day at work?

Begin the research phase.

  1. Find any written artifacts about the audience and use cases.
  2. Get set up so I can perform hands-on experimentation with the product.

What do you like best about technical writing?

The combination of phases in the process: planning, experimenting with the product (research phase), getting multiple perspectives from members of the different disciplines (development, QA, product marketing, support), using the authoring tools to synthesize all that into a practical package, getting feedback, polishing the package for delivery to customers, and maintaining and improving the documentation as user feedback comes in. In an era of specialization, such as test automation, technical writing is one of the rare crafts that involve so many phases, and that provides the craftsperson with a chance to say, "See this product? I worked (with a team) to build and deliver it!" 

Which audience do you prefer writing for?

I enjoy writing for end-users, administrators, as well as application developers.

The subject matter experts are busy people, so how do you manage to get the feedback you need?

The key is to be flexible enough to "connect" with that person. I strive to discover the best interaction style, that is to say, whether that person prefers a wiki posting, an issue logged in a bug tracking system like Jira, a face-to-face conversation, an email exchange, a telephone conversation, or a shared desktop session. Also, it helps to know whether that person is most approachable early in the morning, late in the afternoon, on Fridays, or immediately after a meeting ends.

What do you think about Customer-advocacy and Quality?

The purpose of technical documentation is to allow the customer to do her or his job effectively and efficiently. That "job" is often a set of steps, a workflow, a use case. Although the QA engineer is often a key source of information for the technical writer about the details of a specific feature, the technical writer is often the first  in-house "user" of the product from customer viewpoint, that is, from the workflow or use case viewpoint. Therefore, the technical writer's usability feedback can contribute to improving the quality of the user experience. Typically, I give feedback in meetings and by logging defects and enhancement requests.

By the way, studies have shown that users generally do not like to click a "Help" button, so calling it "Tips" is sometimes better. Best of all is when the user interface is so intuitive for the user's workflow or use case that the user never needs to read documentation. Technical writers can sometimes "embed" Help into the GUI or suggest names, phrasing, use of color, or icons that "trigger" the user's success in making the right choice. Only as a last resort should we burden the user with a topic to read. If a topic is necessary, it should give "just enough" information.

What do you think about single-sourcing?

I think it is the optimal way to be productive. While working in a markdown-to-PHP-to-HTML environment, we lacked a solution for single-sourcing. That forced the technical writers to make the same updates to different copies of the documentation, each time with a risk of information becoming inconsistent between the locations. Single-sourcing can enable us to give users the delivery format they prefer. I have seen Support users retain a preference for PDF even when Web Help is available because they are used to the PDF search feature. Many developers prefer HTML to PDF because HTML code samples are easier to copy and paste without the PDF page breaks.

What is your work history?

2003 - Present Java Instructor, part-time, for UC Berkeley Extension, 30 evenings per year in San Francisco
November 2013 through March 2014 Terracotta Inc., a Java-based start-up in San Francisco that provides Big Data technology on top of open-source Ehcache. Due to the start-up being acquired by a large German firm that tends to centralize and downsize its acquisitions, Terracotta lost its CEO, head of engineering, and various other staff members, including me. I was nevertheless awarded a bonus for having done good work.
August 2010 - October 2013 Accelrys became the name of the Symyx when two companies merged and the headquarters moved from the San Francisco Bay Area to San Diego. I was offered relocation to San Diego but chose to resign so I could join Terracotta Inc.and remain in the San Francisco Bay Area. I worked on Symyx-based products:
  • the DiscoveryGate web service and cloud-based data source
  • the Enterprise Laboratory Notebook used by big pharmaceutical companies
April 2007 - August 2010 Symyx became the name of MDL Information Systems when two companies merged and the headquarters moved from San Leandro to Santa Clara.
April 2000 - April 2007 MDL Information Systems in San Leadro hired me. I joined because I liked the domain: scientific research tools powered by innovative software. Here I learned and documented a scripting language based on JavaScript.
June 1994 - February 1997 Oracle hired me to update networking and installation guides for  the Porting group, and later I transferred to the core database group.

How did you get into Technical Writing?

After I wrote my Ph.D. dissertation on the mutual influence of the relationship between cultures and their national literatures, I taught composition at several colleges in the Buffalo, New York area. When it became clear that tenure-track professorships were difficult to obtain, I returned to California and found a job in a high tech start-up. This job involved writing marketing materials about digital imaging. Eventually, I published an article that made the cover of an important trade magazine, Materials Evaluation The article, in conjunction with a contact I made at a local Society of Technical Communication meeting, enabled me to land a job as technical writer at Oracle.

How did you get into teaching Java?

I enjoyed teaching working adults since my first year in graduate school, so I welcomed a chance to do some part-time teaching of technical writing. U.C. Berkeley Extension brought me on board because I was a technical writer at Oracle and I had several years of university teaching experience. When I decided to earn U.C. Berkeley Extension's Certificate in Computer Information Systems, I took courses in Java. A Java instructor told me that he had too many sections to teach. He supported my proposal to co-instruct First Course in Java with a developer I recruited. After co-instructing the course a few times, I took it over by myself.

Are technical writing and teaching complementary activities?

Yes. Technical writers rarely interact with their customers face-to-face. When I teach Java, often to programmers with many years of experience, I get first-hand awareness of how code developers learn new technologies. Teaching not only reinforces my knowledge of the material, it helps me better understand my readers.