[IEEE IPCC 2005. Proceedings. International Professional Communication Conference, 2005. - Limerick, Ireland (July 7, 2005)] IPCC 2005. Proceedings. International Professional Communication

2005 IEEE International Professional Communication Conference Proceedings

0-7803-9028-8/05/$20.00 © 2005 IEEE.

What Part Writer? What Part Programmer? A Survey of Practices and Knowledge Used in Programmer Writing

Christina Bottomley The University of Washington [email protected]

Abstract

There are few resources geared to technical writers working on documentation for software developers. This paper presents the results of online surveys and telephone interviews that cover the experience, technical knowledge, and practices of technical writers in this area, with a large percentage of respondents who are Microsoft employees. Respondents value strong writing skills and the ability to learn quickly and continuously, with the amount and type of knowledge needed being specific to the subject area and audience for their work.

Keywords: Documentation, Developer Documentation, SDK Documentation, API Documentation, Programmer Writer, Technical Writer

Introduction

The main products of programmer documentation are Software Development Kits (SDKs), which are used to develop software applications with a certain technology or to integrate two pieces of software. SDKs typically contain the overviews, systems requirements, installation procedures, conceptual information, Application Programming Interface (API) references of classes and methods, and code examples. Robust or mature SDKs tend to contain links to detailed background information, white papers, and notes that list hints, tips, and tricks for coding (1).

In practice, this documentation “demands structured content, which begins from a known framework and then expands to new terms and

concepts, analyzing suitable examples, describing unique situations and limitations (2).” SDKs can be difficult to maintain, as developers often resist using or contributing to documentation that they feel is complicated, out-of-date, or otherwise not useful to them (3).

This paper offers a snapshot of the skills and practices used by writers who produce SDKs and related documentation for software developers. These results should be of interest to people developing training or standards for programmer writing and to people who are or are considering becoming programmer writers.

How Research was Conducted

Subjects for this study were contacted through an online survey titled “Interested in or Work on Developer Documentation/SDKs?” which was sent to e-mail distribution lists posted in newsletters for selected companies in the software industry (Microsoft, IBM, and Cisco) and relevant trade and academic groups (IEEE PCS, ACM SIG DOC, STC Technical Editing and Information Design SIGs, and Writers UA). Respondents answered questions about their job title, academic background, length in field, specific types of documentation produced, the audience for their work, the tools they use, the resources they recommend for this work, and their knowledge of programming languages.

For programming languages studied, respondents rated their knowledge of 15 programming languages using the following categories:

• Studied language, not used in work • Edit some code, not fully read • Read code

802


• Produce samples • Produce applications • Subject matter expert/professional

developerThe languages respondents were asked to rate were C, C++, C#, Visual Basic, Visual Basic .NET or 2005, COBOL, SQL, Java, Pascal, Perl, JavaScript, and FORTRAN. The categories approximate knowledge commonly shown by technical writers of various levels and were screened by six programmer writers.

Participants

Of the 72 survey respondents, 38 had more than five years of experience with programmer documentation, 13 had three to five years of experience, 12 had one to three years of experience, and 9 had less than one year of experience. These respondents included 21 programmer writers and 19 technical writers. Programmer writers typically have more programming experience, although the amount and type of knowledge varies by job. For example, a job description for a programmer writer might ask for working knowledge of two programming languages and the ability to write code samples, while a technical writer may or may not be expected to read or write code.

• 18 managers. These include documentation group leads, SDK leads, program managers, writing leads and editing leads.

• 7 technical editors. • 3 people in other professions. These

included two software development engineers and one user assistance lead.

Between them, respondents had 57 bachelor’s degrees, 27 master’s degrees, and 6 PhDs. The most frequently listed degrees were English (19 bachelor’s degrees, 5 master’s degrees, and 2 PhDs), Technical Communication (8 bachelor’s degrees and 5 master’s degrees), and Computer Science (7 bachelor’s degrees, 4 master’s degrees, and 1 PhD). Other degrees held included Creative Writing, Audiology, Physics, and Law. A complete list of respondents’ education appears in Table 3.

For their work, 32 respondents produce conceptual topics, 27 produce API references, 24 respondents write code samples, and 9 produce technical whitepapers. A full list of programming languages studied or used by respondents appears in Table 1. On average, programmer writers reported being able to produce samples or applications in at least three programming languages.

Interviewees Of these respondents, 24 agreed to be interviewed about their work and completed interviews (20 telephone interviews and 4 in-person interviews) between November 28, 2003, and January 10 2005. Interviews lasted between 45 minutes and two hours with the average interview lasting about an hour. Interviewees included one technical editor, three managers, five technical writers, and 15 programmer writers. Their experience writing programmer documentation ranged from one to twenty years, with fifteen people having five or more years of experience.

Seventeen interviewees are Microsoft employees or contractors. The high turnout of Microsoft employees may be due their proximity, frequent use of the discussion list where the survey was posted, and availability due to product cycles. Their responses certainly reflect Microsoft’s tools, standards, and processes. Of the other interviewees, three were the sole writers for their company or group, and two writers work in Europe.

Interview questions covered writing and programming skills, common tasks and methods, resources, advice, and work with developers—both the internal developers who provide resources and the developers who use the documentation. A list of the questions asked appears in Table 4.

Interview Results

“Fell into it,” was the majority response when interviewees described how they started writing programmer documentation. While three interviewees have computer science degrees, the others learned their programming skills on the job, originally coming from areas such as

803


Table 1. Number of Survey Respondents’ Familiarity with Programming Languages

LanguageStudied, not used in work

Edit,not fully read

ReadProducesamples

Produceapplication

s

SME or developer

C 10 5 9 10 8 7

C# 4 5 7 13 11 5

C++ 9 7 15 9 5 7

COBOL 14 3 3 1 1 2

FORTRAN 12 2 4 2 2 4

Java 5 4 3 4 2 1

JavaScript 6 5 9 10 9 3

Pascal 17 2 4 3 5 1

Perl 11 6 3 1 3 2

SQL 7 9 4 17 5 3

Visual Basic 5 8 10 11 11 3

Visual Basic .NET/2005

3 4 7 10 12 1

teaching, testing, tech support, and end-user documentation.

Important Skills All interviewees said that the skills found in other technical writing jobs also apply to programmer writing. These skills include:

• Providing clear and accurate instructions. • Recognizing unclear or incomplete

instructions.• Working well with a variety of people

across different groups. • Using the appropriate level of terminology

for users. • Being a user advocate. • Being a fast learner. • Being persistent.• Being an avid reader.

Overall consistency, conciseness, and the ability to learn high-level concepts while working on low-

level, sometimes disconnected details were frequently mentioned as skills important to programmer writing, as was an active interest in writing and experimenting with programming. Interest in programming is an important issue for programmer writers, as they are commonly asked, “How much of a programmer do you need to be for this work?”

The answer to this question is that programmer writers, like other technical writers, need an appropriate level of knowledge to convey the information needed by their audience. “There are so many ways that errors can creep into documentation, either by not understanding something or getting the wrong version of source code,” said one programmer writer. “Having a development background helps you know the number of things that can go wrong with what you’re writing.”

804


For their work, nine interviewees emphasized writing skills more than technical skills, 10 emphasized technical skills more than writing skills, and five placed an equal importance on both skill sets.

When asked about important qualities for programmer writers to have, responses included:

• You have to enjoy passing information along and putting yourself into the reader’s mind. This can only be trained to a certain extent.

• Get used to dealing with uncertainty. A lot of people get frustrated with Beta software or not knowing the answers and not being able to verify data.

• Don’t worry that you’ll break something when you’re playing with the software. Part of the point is to see what happens when you do the wrong thing.

• There are things a developer would find frustrating about this job. When you’re not writing full applications it is harder to track how much you’re learning.

• Often you’re presented with different claims about how things work from developers, specifications, and your own trials. You need to figure out how things really work.

Finding candidates with right-brain writing skills along with the left-brain programming suited to the output, audience, and technologies of a particular company or group was a problem mentioned by 11 inteviewees. Adding to this problem are the difficulties of quantifying good writing skills, mentioned by six interviewees, and by job descriptions that are vague, inconsistent, or do not accurately reflect actual tasks and responsibilities, which was mentioned by 10 interviewees. Comments about finding qualified candidates included:

• Because of the better pay, people see programmer writing as a step up on the job ladder. Several people have asked me for me for mentorship, but were not interested in writing code.

• We need to focus on details, write quickly, and move on. Gauging someone’s ability to do this is difficult to judge from a few writing samples.

• It’s hard to find people with the verbal skills and the interest in what can be very dry, boring, geeky stuff. Show me someone who loves to do word games like Scrabble—this is a good candidate.

Technical Knowledge Suited to User Needs Interviewees offered strong opinions about the skills and knowledge necessary to produce programmer documentation, with the ideal candidate being able to predict and respond to user needs. These users can include novices or hobbyists, developers using new technology, or developers whose experience is in other areas. In other words, programmer writers cannot always assume that their users are experienced developers—one study found that developers were often less qualified than expected by their company or were not the correct people to develop applications using the SDK [4).

As the end-user audience for this documentation, developers have been shown to want [4):

• Documentation that they can reference quickly, when they have a problem.

• Code samples that they can cut-and-paste into their own applications.

• Cross-reference to terms used by other companies.

• Guidelines and directions for using programming that focus on how, not why, to do things.

• An explanation or demonstration of the technology.

• Descriptions or demonstrations of the types of applications that can be developed with the SDK.

To learn specifics about users, 17 respondents mentioned using resources such as team e-mail aliases, online discussion groups, conferences, product demonstrations. Three respondents were contractors or consultants who reported having either no or rare contact with users. Two writers supported internal groups, using team meetings and interviews to gather information on users. Interviewees had the following concerns about addressing user needs:

• Understanding user needs is not always easy. I do this in part by writing applications, this is the first line of defense, and by following user feedback for issues to address.

805


Table 2. Interviewees Assessment of Programming Knowledge Needed for Their Work Level of

KnowledgeArea of Work Technical and Programming Knowledge Needed

Must be aprofessionaldeveloper

• Gaming platform documentation, including SDK and whitepapers for intermediate to advanced audience.

• Two or more years of experience as a developer. Working Knowledge of C++. Writers need to provide tips on how to optimize the platform. For example, “Top 10 things to think about when designing memory management.”

Must write codesamples and applications

• Visual Basic sample applications and code examples.

• Documenting Windows Client SDK.

• Documenting Windows Tablet PC SDK.

• Ability to write 1,000 line sample in Visual Basic and knowledge of coding best practices. Knowledge of .NET Framework.

• Knowledge of .NET Framework and of how managed code works. Document declarative markup languages. Compare competitive versions to explain differences. CS degree preferred, although hiring achieves a variety of experience and backgrounds in group.

• Ability to write code in two languages (one managed, one unmanaged). Ability to explain Tablet PC functionality to live users.

Must read code

• Windows Media User Assistance.

• Documenting Open Source Science and Engineering Software.

• Technical editor for SDK.

• Knowledge of new product features,, C++, and COM. Knowledge of media concepts such as video standards, content delivery, and compression/decompression.

• Read Python and Java. Run tools to generate API documentation from source code comments and understand classes and relationships.

• Developmental and technical edits of SDK. Works mostly from functional specifications. Examine code and routines to see that they make sense. Working knowledge of programming and programming concepts, especially as they pertain to C++, C#, and VB .NET.

• Giving the right amount of detail is difficult, especially when describing code that people usually aren’t looking at directly. We unfortunately tend to leave out details for beginners once we learn the technology.

• Developers will tell you what the APIs do and how to use the API in various ways,

but they don’t necessarily understand the user’s view of needing information to solve a specific task.

A broad estimate of the skills needed to write programmer documentation may be influenced by a trend noticed by four interviewees for job descriptions with increasingly demanding

806


qualifications that do not reflect actual work. Interviewees’ comments about these hiring practices included:

• Most groups at Microsoft seem to really want someone with a Computer Science degree. I don’t know if I’d get the same job in 2004 that I got in 2001—it would probably go to an out-of-work programmer.

• People often don’t realize that if you had a Computer Science degree it would be harder to document Visual Basic. The typical user doesn’t have a Computer Science degree.

For their particular work: • Nine interviewees stated that their skills

needed to match or exceed those of their audience.

• Twelve said that they supplement their knowledge with resources such as personas, customer feedback, help from other writers, and interviews with subject matter experts and developers.

• Five said that having certain novice skills benefited their work, as their readers were less experienced programmers, or the writers believed that their inexperience helped them identify and work through programming problems.

A more concrete look at the skills interviewees use for their work is shown in Table 2, which lists examples of the skill level and output of six programmer writers and one technical editor. While everyone said that programming knowledge was important to their work, only the programmer writer for the gaming platform said that programming knowledge was as or more important for his work than writing skills. Interviewees who said that technical and programming skills were more important for their jobs also reported shorter ramp-up times to produce work.

Recommended Ways to Learn Skills Overall, interviewees said that prospective programmer writers need should be prepared to learn “bit-by-bit,” for example, having a mentor suggest some high-level reading and then experimenting with a small piece of code or documenting a simple topic. Interviewees reported learning about 80 percent, with one person reporting less than 50 percent, of their current

programming skills through their work. Ten interviewees did not consider their programming or technical writing classes to be formal training for producing programmer documentation.

Interviewees said that the standard format of most programmer documentation and high-level similarities between programming languages helps them focus on learning and writing. When learning a new programming language or technology, interviewees favored:

1. Taking classes (including internal company training). Respondents who favor classes over books said that classes help them learn fundamentals quickly, although one believed that classes are “grossly overpriced and address the lowest common denominator.”

2. Keeping a collection of reference books in addition to books for current studies.

3. Asking coworkers for information. This includes getting walkthroughs and code examples to review, including code examples with known bugs so writers could learn how to recognize specific errors.

4. Examining previous versions of product or technology.

5. Performing online searches, especially as a quick introduction before talking to others.

For those new to programmer writing, interviewees offered the following advice:

• A thousand APIs is like a knot that will come loose. Find a piece you can get a handle on, start tugging away, and unravel it from there.

• You never know what prior skills will help you. You have a much wider set of knowledge as a writer, while a developer has more depth.

• To learn a language, skim the Internet to figure out how to get a “Hello World” program working. From there, use existing documentation and the compiler error messages to grow the program into something more useful.

Producing Documentation While technical skills and programming knowledge varied widely, the processes and resources writers use are fairly similar. These

807


processes reflect the modular, hierarchical structure of programming documentation and help the writers concentrate on obtaining and updating information.

Interviewees’ input into tools and templates varied widely. “Often a tool is pushed on teams and the writers have to deal with the tool to get their work out,” said one program manager. “It’s up to management to give them access to planning, and writers have right to voice if this isn’t happening.”

Six interviewees said that they had limited input into production tools, but often felt that their input and feedback was not taken into account. Interviewees said that strict content and formatting standards for reference standards were reasonable, but sometimes felt constricted by the use of similar standards for conceptual documentation.

Interviewees appreciated having formal technical reviews and handoff processes, along with the option to create tools to automate their work. Sixteen interviewees said that automation provided either by their own tools or their team’s tools were very important for their work.

Working with Specifications When documenting a new area, writers are advised to ask “‘What will the SDK allow a developer to do?’ and ‘What does a developer who knows nothing about the current technology need to know to write code [1)?’” To find this information, two-thirds of the interviewees said that they first read the functional specification, while or while not also looking at code, while the others first look at just the code or talk to a developer or program manager. Specifications are used to:

• Obtain general product information. • Form questions for developers or program

managers.• Create outlines of topics to cover. • Write first drafts of topics, when

specifications contain enough detail.

Out-of-date or incomplete specifications were a common problem mentioned by 10 interviewees. Those who work with managed code as part of the .NET Framework said that they compare specifications against the code structure exposed in managed code to identify new or out-of-date information. Others use their coding skills to test information in the specification. Interviewees

recommended the following steps to help track and confirm information in specifications:

• Save local copies of specifications to a personal computer to create a version history.

• Save e-mail inquiries to program managers and developers.

• Meet with developers for updates before documentation is sent to them for a technical review.

Interviewees said that out-of-date specifications are still useful when beginning research, tracking project history, and deciding what to cover in documentation. “They give you a vision of how developers originally intended things to work and a way to track design decisions,” said one writer. “You can look at what was cut and then combine method calls to get back a functionality.”

Steps in Producing Documentation Theiterative, research-review-revise process described by interviewees for their work would be familiar to most other technical writers. Interviewees prefer starting this process as early as possible in the product cycle, and said that learning about early planning and design through attending design meetings was especially useful.

Along with use of managed code and up-to-date and complete specifications, interviewees frequently mentioned the following as important factors in how they produce documentation:

• Familiarity with the product and technology.

• Available time. • Access to developers and program

managers.• The product’s state. This can include an

updated version, a Beta version, a new product that exists only in specifications, and an incomplete or unstable version. For products where code is not yet available, interviewees rely more on specifications and interviews to begin documentation.

Especially when short on time, interviewees work with or rely on their managers or program managers to prioritize the functional areas and topics to cover, although both functional areas and topics often change during a product cycle. Interviewees try to talk to developers, program managers and other people who serve as

808


information sources at any time during their work when they have questions or want to confirm that information is accurate or has not changed.

About a third of the interviewees first try to interview the program manager before examining the specification or source code. Interviewees who work with managed code run a tool to generate an outline of the API. Two interviewees review code before creating a plan of topics to cover, which they then send out for feedback and approval.

Either by using a tool supported by managed code that shows structures and classes or by identifying headers in code, interviewees then examine the code for comments, to understand the hierarchy and inheritance. They then begin writing their own code, calling the properties and methods of the source code to understand what users can do with the API. Corrections and updates to reference topics can come from technical reviews or user feedback, such as product bugs or newsgroups.

Working with Developers & Program Managers Overall, writers had positive experiences with their developers, usually achieved over time through consistent interactions that were tailored to individuals. Most interviewees mentioned program managers and developers in unison as resources for finding information, with program managers being mentioned as valuable resources for prioritizing information to cover, learning about new features, getting specification overviews, and defining production processes.

Interviewees frequently stated that their knowledge was a benefit when working with developers, especially as most writers worked in different groups than developers. This separation and writers’ perceived lack of knowledge adds to developers’ perception of documentation being a support task that is separate from the product. Seven writers specifically mentioned that they would like to see integrated development, documentation and test teams at their companies.

While the ability to write code was considered the best advantage for working with developers, writers also recommended:

• Accurately learning developers’ terminology.

• Attending their meetings and offering help with naming conventions and on user perspectives.

• Attending group social functions. • Asking specific questions and showing

signs of researching answers in advance. • Talking to developers in the hallway.

Other advice offered for working with developers and program managers included:

• Thank them for their time. Don’t make demands on them as if they owe you something.

• Be meticulous and accurate to ensure that the documentation is something they can use themselves.

• To know what’s coming you have to inject yourself in early on. People now come to us and ask for our input when writing specifications about APIs. It takes time to train them about the value we can provide.

• I tell my developers and program managers, ‘Please don’t be annoyed by my ignorance. My ignorance puts me where the reader will be. I won’t have it for long.

Working with Testers Testers are typically underutilized in documentation, according to interviewees who found that testers were more willing and available to explain their work compared to developers. One writer noted that testers and writers share similar responsibilities, but often use different methods to accomplish their work, which make it hard to collaborate.

Interviewees recommend working with testers to: • Confirm suspected bugs. This also benefits

testers who receive credit for finding bugs. • Learn how to call the APIs • Experimenting with their test code. • Learn about edge use cases. • Hold interviews about specific features

and watch testers run their code.

Conclusions

Interviewees believe that the writing and technical skills required of programmer writers are a rare combination to find in applicants. These results do not fully address the programming and technical knowledge asked of programmer writers outside of Microsoft or the exact contact that technical writers have with programmer documentation.

Respondents value skills important to other technical writing jobs such as concise writing,

809


clarity, accuracy, audience knowledge and being a user advocate, as well as breadth in education and general technology knowledge. They agreed that people interested in programmer writing need to be willing to read and write code, and also be willing to learn new programming languages and technologies over time.

Programmer writers stressed that their ability to write code helps them understand their users and helps ensure accurate documentation. While the majority of interviewees felt that good writing skills were more important than technical skills, they all indicated that a technical background or a strong interest in learning technical skills was important for their work. Almost all interviewees stated that learning was their favorite part of their work, along with problem solving, and being around smart people.

Table 3. Respondents’ Education For the survey question” What degree(s) have you earned or are earning (for example, ‘Certificate, computer science and B.A. English’)?” respondents gave the following answers:

16 listed certificates (notincluding individual classes)

C programming, Computer Science, data processing, French, Java 2 platform programming, Java programming, MSTE, project management, teaching, technical communications, technical editing, technical writing

57 listed Bachelor’s Degrees, with eight respondentslistingeither two degreeseach or doublemajors

Animal Psychology, Anthropology, Astronomy, Biology, Business (3), Communication, Comparative Religion, Computer Science (7), Education (3), English (19), Electrical Engineering (2), French, Gender Studies, Humanities, Information Systems, Journalism, Mathematics (2), Nursing, Philosophy (2), Physics, Political Science, Psychology (2), Speech Pathology, Technical Design, Technical Communication (8), and Visual Arts (2)

27 listed Master’s Degrees, with three respondentseach having twomaster’s degrees

Audiology, Biomathematics, Communication (2), Computer Applications, Computer Science, Creative Writing (2), Economics, Education, English (5), French, Journalism, Library Science, MBA (2), Performing Arts Management, Science Management, Software Engineering (2), Spanish, and Technical Communication (5)

6 listed PhDs

Computer Science, English (2), Geophysics, Law, and Microbiology

810


Table 4. Interview Questions What qualifications would you list in an advertisement for your job?

Have you had what you consider formal training for this work?

How would you advise a new programmer writer/technical writer to approach their work?

Do you see any barriers to entry for this work?

What is the most challenging aspect of your work?

Have you found any writing skills particular to this work?

Knowledge

For your most recent project, what background knowledge did you need?

How long did it take for you to acquire this knowledge?

When starting a new project, how do you approach it differently if you don’t have a background in the group, product, or technology?

How do you judge if a specification is out-of-date?

Work with and Knowledge of Programming

How would you overcome a lack of programming background?

Specifically for your work, how important is it to have a developer’s mindset?

How much of your programming knowledge have you acquired directly through work?

How much do you rely on automation?

Do you run the software that you document?

Tasks & Processes

What is the major task for your job?

Breakdown your current project into major

tasks (for example, editing code, interviewing, researching, writing conceptual information, using the application/project, etc) and estimate what percentage each task takes.

What are the steps you go through when working on a typical project or section?

What would you change about the process you work with?

Resources

What is the level of collaboration for most projects (between writer and between yourself and the people you use as resources)?

How do you get help/resources (existing documentation, subject matter experts, other writers, developers)?

What is your advice for working successfully with developers?

What input do you have into planning, tools, doc model, and where would you like to have more input?

Audience

What is important for you to know about your audience?

What direct contact do you have with users?

Necessary Skills

What qualifications would you list in an advertisement for your job?

Have you had what you consider formal training for this work?

How would you advise a new programmer writer/technical writer to approach their work?

Do you see any barriers to entry for this work?

What is the most challenging aspect of your work?

Have you found any writing skills particular to this work?

811


Table 5. Tools Used For the question, “What tools do you use to produce this documentation?” respondents gave the following answers (Please note, respondents were not asked to provide a comprehensive list):

Microsoft Word: 49 (including modified versions) In-house/proprietary tools: 34 (8 mentioned SGML or XML-based tools) Adobe FrameMaker: 11 Macromedia Homesite: 9 Macromedia RoboHelp: 7 Microsoft Help Workshop: 8 Macromedia Dreamweaver: 5 Microsoft PowerPoint: 5 Corel XMetaL: 4 Microsoft Visual Source Safe: 4 Microsoft Visio: 4 Microsoft FrontPage: 3 Microsoft Notepad: 3 Microsoft Excel: 2 Arbortext Epic Editor: 2 Microsoft Visual Studio: 2 Tools listed once: Adobe Acrobat, AllFusion ERwin Data Modeler, Altova XML SPY, Doxygen, IBM DITA, IBMIDDoc, Jacs Paint Shop Pro, Javadoc, Microsoft Paint, Microsoft Visual Basic for Applications, Microsoft XSLT Inference Tool, Mirek, MWSnap, Multi-Edit, OpenOffice.org, Quark, Source Forge Epydoc, WordPad, XEmacs.

References

[1] John T. Sarr, “Creating an SDK: Writing on the edge,” STC Intercom, pp. 22-24, June 2001.

[2] Pawan Nayar, “Ten Misconceptions about Software Documentation,” STC Intercom, pp. 27-29, May 2000.

[3] Timothy Lethbridge et al. “How Software Engineers Use Documentation: The State of the Practice,” IEEE Software, pp. 35-39, November 2003.

[4] Janet Nykaza et al., “What programmers really want: results of a needs assessment for SDK documentation,” in Proc. of the 20th annual international conference on Computer documentation. Toronto, Canada. ACM SIGDOC. June 2002, pp. 133-141.

Acknowledgements

Thank you to the interviewees for taking the time to talk about their work in such detail, as well as the survey participants and those who helped distribute the survey link.

About the Author

Christina Bottomley has a Master’s Degree in Technical Communication department at the University of Washington, where she studied computer documentation. During this research project she was a technical editor for Microsoft Visual Studio User Education. She has been a technical writer for Microsoft, RealNetworks, and Amazon.com.

812

Documents

[IEEE IPCC 2005. Proceedings. International Professional Communication Conference, 2005. - Limerick, Ireland (July 7, 2005)] IPCC 2005. Proceedings. International Professional Communication