Simple Writing Commandments

• Use active voice. Use passive voice only to obscure the subject.
• Be measured and precise: choose your words carefully.
• Structure your writing so that each paragraph or section has a unified focus.
• Keep paragraphs ``bite-sized''.
• Hyphenate correctly.
• Use an appropriate and consistent level of formality.
• Eliminate unnecessary words.
• Prefer simple and direct constructs to more complex ones.
• Use "which" and "that" correctly.
• Don't rely on fluff words like very or extremely to strengthen your points. In the words of the immortal Mark Twain: Substitute "damn" every time you're inclined to write "very"; your editor will delete it and the writing will be just as it should be.
• Use a spell-checker.
• Avoid redundancy.
• Strunk your own text before you give it to me.

In my time as a professor I've read hundreds of draft papers from students. Students tend to make the same errors in the early period of their development. Some students make the same errors repeatedly. Old habits die hard.

The most fundamental challenge is to organize and linearize a complex thought process and a lengthy research process into text that seems simple and straightforward to a reader. Students often seem to resist it, because deep down they feel that all the hard work they have done couldn't possibly distill down to a simple paper. Resist the temptation to make things sound more complicated than they are. Simplicity and elegance always win in the end.

A good technique for organizing is to start with what is essential. The intro for any paper must be short, but it must communicate essential information to the reader:

• Show Relevance and Elegance
• Present a Problem, a Premise, and a Proposed Solution
• Clearly Capture:
  • Current Context
  • Constrained, Coherent Scope
  • Creative Concept
  • Calibrated Claims and Contributions

The intro should never contain technical details: push them back and craft your intro around the essentials. For the rest of the paper, each detail has a rightful place in a logical progression of sections. The exact structure might be domain-specific, but for systems papers the classic structure is:

• Overview
• Related Work
• Design
• Implementation
• Evaluation

Essential "big picture" details should show up in the overview, along with enough related work to set your work in context, but not so much as to define your work in terms of others. Define categories of related work in the overview, cite the relevant papers in lists, and forward reference a related work section that discusses them in more detail in the back.

A key purpose of the overview is to define terms. Pick terms carefully, define them clearly, and use them consistently. Finding the right terminology makes all the difference. Language shapes thought.

At the end of your overview (3 pages), your readers should understand why they should read the rest of the paper, or why they should recommend its acceptance. They should know what the rest of the paper says, why it is important, and how it builds on the state of the art. All the rest is execution. Execution is critical, but it is worthless unless the context is clearly established and accepted. The execution may be incoherent without the right structure to hang the details on. Context is essential.

Any detail that is not essential to establish context has some rightful place in the DIE sections. Design should be broad enough to encompass a range of instantiations of the key ideas, not necessarily limited to what you actually implemented and evaluated. Don't mix implementation details into design.

Depending on the work, the heart of the paper is either design or evaluation. Structure appropriately. Do your ideas propose a new architecture, a new way to think about or approach some set of goals? Or does it propose a better way to achieve some particular goal?

Evaluation begins with methodology. A reader who does not understand and accept the methodology will not read the results. Every figure includes a caption that tells the reader what to conclude from the figure. It should be possible to understand the entire performance section by reading the figures and their captions.

When I mark up papers, I use a few custom notations for common errors:

• NE. Not English. Indicates that you have made an elementary grammatical error (e.g., missing verbs, incorrect subject/verb agreement, or whatever) that renders the sentence incoherent.
• WIM. What's It Mean. Indicates you wrote something that probably sounds good to you but whose meaning is not clear to others.
• WAYS. What Are You Saying. Indicates there is a good strong thought hiding in a thicket of words. Bring out the thought and burn down the thicket.
• ER. Eyebrow Raiser. Indicates that an essential claim or assertion should be calibrated more carefully, or requires more substantiation.
• Assert. Indicates you made a questionable assertion that is not essential to the argument. If a reader finds your assertion to be false, it will throw an exception and spew errors rather than reading the rest of the paper. Limit your claims to those that are essential to the point of the paper.
• Shun. Indicates that your text overuses multisyllabic words that end in "-tion". The sound bite is: "shun -tion". Some of these words show up often enough in our field (information, application, reservation, utilization), and we don't really need any more if we can avoid it. "Shunning" is one specific example of the more general problem of "nouning" verbs. Use the verbs themselves whenever you can. E.g., "it is important that the specification and implementation of the module be done correctly" becomes "it is important to specify and implement the module correctly". As a side benefit, it replaces an unnecessary passive voice with something more active! Note the placement of "correctly": if I said "to correctly specify" then it would be a split infinitive error which is known to annoy prominent members of our community.
• NS. Non-sequitur. Something does not flow naturally from what precedes it. This is often the result of an editing error, e.g., when the writer migrates or deletes text and does not repair the "connective tissue".