Preface

Throughout grad school, you'll read hundreds or even thousands of technical papers. The quality of these papers is highly variable. These are some tips that I've picked up in reading papers, revising with professors, and receiving reviewer feedback. Hopefully these are beneficial to CS grad students looking to improve technical writing skills (both in style and content). Given my background, the specific focus of these tips is more on systems and networking research.

You can go to my publications page to see examples of papers that I've written Also, all papers co-authored by my adviser are available on his research group's site.

Related Pages

• LaTeX HOWTOs

Tips

1. Learn to Use LaTeX: MS Word may be easier to work with in the short term, but using LaTeX has far more advantages in the long term. It is much more customizable and has a large base of open source packages available. Additionally, it is ASCII-based so you can use your favorite editor (which should be more efficient than the Word interface) and use revision control systems (e.g., RCS or CVS). Some of these tips discuss LaTeX packages that I've found useful.

2. Focus on the Abstract, Introduction, and Conclusion: The general structure for papers is:

   1. Introduction
   2. Related Work (sometimes this comes before the Conclusion instead)
   3. Your Design
   4. Evaluation of your Design
   5. Conclusion and Future Work

   The evaluation of your design consists of at least one of the following: either analysis, implementation, or simulation.

   What you need to remember is very few people are going to read the whole thing. Most times, people are reading to get the overall idea of what you did and don't care about the minor details of your design or your discussion of a cross-over point in a graph. This includes reviewers. Sometimes reviewers are responsible for evaluating 30 papers for a single conference. Thus, your paper should ideally be designed to convince people glancing over it of the work's significance as well as provide enough detail that a subset of more interested readers could repeat your results.

   This means that the abstract, intro, and conclusion are of utmost importance for the purposes of convincing reviewers that your work is significant. The intro should give some background on the problem being addressed and its importance, give an idea of why existing solutions are not adequate, and the contribution of your approach. Obviously, knowing your audience is important. If you're submitting to a general networking conference, the intro may need to be higher level than if it is being submitted to a wireless networking conference. The conclusion briefly reiterates the intro and summarizes the significant knowledge gained by evaluating your design. The abstract is generally similar to the conclusion, but more succinct.

3. Use Bullet Points Liberally: Given that most readers will be skimming over your paper, using bullet points for descriptions is an effective way to structure the paper. For example, when you list your key contributions, a reader is much more likely to see them in a bulleted list than if they're buried in the text. A numbered list can be effective in giving a high level overview of the steps in your protocol or algorithm. While the details are in the text, a skimming reader can easily get an idea of how the protocol or algorithm works. In the evaluation section, a bulleted list is a good way to describe the protocols being tested and gives the readers a quick reference when they're glancing at the curves in your graphs.

4. Categorize Related Work: This isn't always doable, but it's helpful whenever you can do it. Rather than just throwing all your related work together, try to find a taxonomy for the related work and divide it into subsections. This then allows you to better explain how your work fits in relative to the previous work (tables may be a nice way to summarize the classification). Maybe previous work used one approach or the other and yours is a hybrid. Maybe you can form quadrants based on orthogonal techniques and your work fills a quadrant that was previously unexplored.

5. Spell Out Acronyms the First Time: Obviously, there are exceptions to this rule. If your reader doesn't know what IEEE or TCP/IP mean, then they're wasting their time reading the paper anyway. But for acronyms of research protocols, for example, it usually helps the reader to write out the entire name the first time you use it, followed by the acronym in parenthesis. An acronym that you mention every day may be completely new to your reader.

6. Useful LaTeX Packages: These are the packages that I've found useful in my papers. The italicized ones were included in my LaTeX distribution. The non-italicized packages are ones that I downloaded and installed separately. See my LaTeX HOWTO for how to install additional packages in Linux.

   • amsmath, amsfonts, amssymb
     If you typeset any equations, you're probably going to run in to a situation where you want to do something like split an equation across multiple lines or add a QED symbol for a proof. These packages handle this and much more.
   • enumerate
     This is handy if you want to change the style for an enumerated lists. For example, if you wanted to use Roman numerals instead of the standard numbering, you can do:
     \begin{enumerate}[I.]
   • graphicx
     This packages helps you include graphics in your document.
   • cite
     This package is useful for grouping citations in your text. For example, if you cite four sources in LaTeX it usually looks like this [1,2,3,4]. With this package, it instead looks like this [1-4]. This can help when you're tight on space and looks nicer when you're citing a long list of sources. Also, it automatically sorts the list so instead of citations like this [14,5,8], you get the more user friendly [5,8,14].
   • url
     This makes handles line breaks in URLs and allows you to specify a font style to use for URLs to separate them from regular text. Without this, LaTeX's line breaks for URLs don't work very well (e.g., hyphenating where there wasn't a hyphen).
   • psfrag
     This package has proved extremely useful to me. Basically, the problem is if you use, say, an graph in the EPS format and one of the axes refers to something you have denoted in the text as a Greek symbol with a subscript. Adding such symbols in the EPS file that match your document's font can be difficult if not impossible. What this package allows you to do is in insert a text tag in the EPS file and then replace instances of the tag with LaTeX commands when it is placed in the document. For example, I could add the text "ALPHA" below the axis in the EPS file and when it is imported into your document, replace the ALPHA tag with $\alpha_i$.
   • IEEEtrans
     A very nice package for creating documents that adhere to the IEEE conference and journal formats.
   • subfig
     This allows you to group related figures such that one is, for example, Figure 1(a) and the other is Figure 1(b).
   • newalg
     This allows you to write pseudo-code like that in Introduction to Algorithms (a.k.a., CLRS style pseudo-code).
   • threeparttable
     I find this package useful if you need to add footnotes to a table entry.
   • tabularx
     This resizes table columns automatically to fit within a fixed width.
   • moreverb
     This allows you to handle TABs in your verbatim input and can include line numbers.
   • latexmk
     This isn't a package, but a command line script that makes LaTeX generation easier by automatically handling dependencies, conversions, and refreshing your output viewer.