Technical Writing for Computer Science Part 1: Content and Organization Research Careers Lecture Series July 13, 2009 Michael J. Lewis, Director Department

Technical Writingfor Computer Science

Part 1: Content and Organization

Research Careers Lecture SeriesJuly 13, 2009

Michael J. Lewis, Director

Department of Computer Science

Binghamton University (SUNY)

NSF REU Technical Writing

CS Research Papers

Every paper is different, but most should be organized like this:• Abstract

• Introduction

• Related Work

• Design

• Implementation

• Performance

• Summary and Future Work

• References


CS Research Paper (cont.)

Abstract• 150 – 300 words

• Identify the problem

• Some background OK, but get to the point

• Identify the key contribution explicitly

• don’t let others decide

• Don’t keep secrets… report the main results

• Many more people will read your abstract than your paper…


Introduction

Do not start with a quote! Provide some background

• (1-2 paragraphs) Get to the point Identify the problem (yes, again) Identify your contribution (yes, again) Preview most important results (yes,

again)


Related Work

Report the background research• Categorize other papers

• Briefly summarize them (1-2 sentences each is often all you have room for)

• Draw the most important distinctions with your work

• About ½ to 1 page…


Related Work: How?

People (your advisor, graduate students, other professors, etc.)

Manuals, websites, specifications, etc.• If it’s not officially “published,” be careful

• Use Wikipedia for trivia about Saturday Night Fever

• Do not use Wikipedia for CS background research

Published research papers


Why?

Research must be new• Otherwise it’s a waste of time

• Especially important if it’s an “old problem”

Others have good ideas you can build on• Reading other work can spark ideas

• (it can also inject biases, be overwhelming, etc…. no magic answer to this problem…)

Others may identify problems for you• They may also show which problems are “too hard”

• E.g. NP-Complete problems need heuristics


CS Publications

(from the “Publishing Game” talk...) Publication Venues

• Journals

• Conferences

• Workshops

• Technical Reports

You have to find everything


How do you find “everything”

Build a list of venues that are likely to report research on this topic• Talk to your advisor and other group members

• Browse conference lists, look at "Calls for Papers“

• Browse by key words to find some recent papers

• Google, Google Scholar, INSPEC, ACM Digital Library, IEEE digital library

Check the last several years of proceedings in these venues • Online or printed copy in the library


Find some papers

Now get your hands on some papers• Read them -- are they relevant?

• If so, they’ve probably cited relevant work• Go find those papers, too

• Use the Related Work and Reference list of relevant papers, to find others• Use title, author, conference, etc.


Browse by Author or Group

Make sure you get the latest work from the group or author of relevant papers• Statements in a paper are only necessarily true at the

time it is published• “open problems” may be solved

• Performance numbers may be irrelevant

• “new” approaches may be old…

• Find the author or research group’s Web page• Don’t count on it being up to date!

• Browse databases/libraries by author


Shortcuts

You will not be able to read everything thoroughly• You don’t have to!

• (notice before I said you have to find everything)

• Read abstract, intro, related work, summary• Then decide whether to read the whole paper

Gold nuggets in your background research• “Taxonomies”, or “Surveys” (not always called that)

• E.g. ACM Computing Surveys


Use Citation Counts and Info

Some papers will pop up over and over• Make sure you read and cite these

• If only for practical reasons… for reviewers to see…

Google scholar and Citeseer• Reports citation counts

• Read and cite the heavily cited papers (see above)

• Allows you to browse by “Cited by…”• If others are citing the same work you are, they might be

working on similar problems


Writing a Related Work Section

Group and categorize other approaches Distinguish your work succinctly Be diplomatic and nice Start with the most “important” work If something is very closely related

• Describe it in more detail

• Be more specific about differences Make it clear why (you think) your paper is

novel


Brief aside…

Make it easy for others to find your work• Pick good titles for your papers

• Post your papers on a web page

• Post full citations on your page

• So others can simply cut and paste into their papers

It’s easier to stay “current” than to get current• Track top conferences, related groups, and authors

• Seek them out at conferences and talk to them

• Potential for collaboration

Staying current is like eating healthy and exercising…


Design and Implementation

Depend heavily on content of the paper

Best to separate Design from Implementation• But not always… and sometimes impossible

Not every implementation detail is important• Focus on those that are novel and important to the

contribution of the paper


Performance

Clearly describe your experimental setup• Ideally others should be able to reproduce your results

• Computer scientists seldom achieve this goal

Then describe your results• Capitalize “Figure 1” but not “this figure”

• ALL figures and tables should be called out in the text

• Interpret the results and “lesson” of every graph, figure, table, etc.• Don’t require the reader to do this for himself or herself…


Summary and Future Work

Say what you’re going to say (Intro) Say it (Body) Say what you said (Summary)

Summaries are not Conclusions

• Draw conclusions throughout the paper

Future Work

• Show that there’s more to do… don’t reveal too much


The Process

You do not need to set aside a whole day!• Write in small blocks of time

• Reread often, later, on paper…

Get a first draft done, somehow, fast• This is the “clay” to sculpt from

• But be willing to throw away most of it eventually


Miscellaneous ideas

Be clear… “Hold the reader’s hand”• Assume your reader is lazy

• Make it easy to find the information

Focus on contributions, not the journey Name new things…

• acronyms, capital letters, descriptive names, bold face or italics (the first time), etc.


Other Sources

How (and How Not to) Write a Good Systems Paper

• A classic… still relevant

• http://www.sigops.org/advice.html

Writing a Technical Paper, by Michael Ernst

• http://pag.csail.mit.edu/~mernst/advice/write-technical-paper.html

Documents

Technical Writing for Computer Science Part 1: Content and Organization Research Careers Lecture Series July 13, 2009 Michael J. Lewis, Director Department