Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


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

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

2 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

3 NSF REU Technical Writing 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…

4 NSF REU Technical Writing 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)

5 NSF REU Technical Writing 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…

6 NSF REU Technical Writing 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

7 NSF REU Technical Writing 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

8 NSF REU Technical Writing CS Publications (from the “Publishing Game” talk...) Publication Venues Journals Conferences Workshops Technical Reports You have to find everything

9 NSF REU Technical Writing 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

10 NSF REU Technical Writing 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.

11 NSF REU Technical Writing 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

12 NSF REU Technical Writing 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

13 NSF REU Technical Writing 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

14 NSF REU Technical Writing 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

15 NSF REU Technical Writing 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…

16 NSF REU Technical Writing 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

17 NSF REU Technical Writing 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…

18 NSF REU Technical Writing 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

19 NSF REU Technical Writing 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

20 NSF REU Technical Writing 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.

21 NSF REU Technical Writing 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


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

Similar presentations


Ads by Google