Company Name: Texas Instruments, Houston, TX
Job: Technical Writer
Dates: August 2002-February 2006

LinkedIn Testimonial: Project Manager Dana Smith

Introduction: Digital signal processors (DSPs) are the little chips in cellphones, wifi card, HDTVs and digital cameras that convert analog signal to digital signals (and vice versa). Texas Instruments is the #1 seller of DSPs worldwide, and one reason customers prefer a TI solution is that TI’s software development kit includes a number of powerful software tools.

During the years I worked at Texas Instruments, the most important development tool was a mature full-featured GUI software tool named Code Composer Studio Integrated Development Environment (which was included in every development kit). Code Composer Studio IDE was a Windows-based tool with a major release generally every two years and minor releases every six months. In fact, new features were being added continuously to Code Composer Studio and often introduced for individual hardware platforms. Writing documentation for CCS was a team-effort; although I probably “owned the project” more than anyone in my group, other writers in our group provided key components to it.

My task/challenge was to manage this chaos! I managed the main project, which consisted of about a dozen smaller subprojects. When I started at TI, the help project (if you combined everything) already consisted of several thousand help topics. I had to maintain the documentation and add new help topics when needed.

See also: more detail about my TI work projects and writing samples from TI and other companies.

End User/Intended Audience: new customers & existing customers wishing to upgrade.

During my work at TI, I produced two “What’s New” guides. These were 8-10 page documents that were released on the website whenever there was a major release.

• Code Composer Studio IDE Getting Started, v. 3.1 (PDF)
  
• Code Composer Studio IDE Getting Started, v. 3.2 (PDF)
  

These two documents provide a user-friendly view of the new features in the new software product. The aim was to make a persuasive case for upgrading.

To obtain the information for these documents, I used existing online help which I created (along with other team members) during the early phases of product development. Later, I worked with the product’s marketing team to figure out which features to emphasize and how they would benefits to the user. I drafted the original document but amended it several times during the draft phase to incorporate suggestions from reviewers.

Tools used: Initially, we used an in-house Unix-based content management system to generate PDFs. Later, my company started migrating all their documentary repositories to be XML-based, so for the second one I used the XMetal XML editor to produce structured XML content (using an in-house DTD) which later was transformed by the Astoria XML document repository into PDF content.