This is a post on how I write research papers.

It’s okay to disagree, since there are many approaches to writing. But if you disagree a lot, then it likely means we shouldn’t collaborate.

Prewriting

Before writing, you should be able to answer the following questions about your work (this is the Kent Beck four sentence abstract):

1. What is the problem?
2. Why is the problem interesting?
3. What are you doing to solve the problem?
4. What follows from this work?

You should ask yourself, “Why is this science?” (from Mladen Vouk). There are many interesting things you can write about, but not all of them are considered science.

Next, you should identify what is interesting about your work from: Murray S. Davis, “That’s interesting! Towards a phenomenology of sociology and a sociology of phenomenology,” Philosophy of the Social Sciences (1971).

“Little is known” is not an interesting reason. Maybe little is known because the topic is so boring that no one cares. “Increasingly interested” is also not an interesting reason, since what goes up must come down.

If your research is on software engineering, you should first run your idea by a few software engineers. If your research is on data science, you should do the same with data scientists.

Don’t write papers on non-problems.

Pick a Conference

I pick a conference before I write the paper. This gives me a target date and also a sense of the work that needs to be done.

I select a set of template papers from this conference and model my own writing after them.

These template papers are your nearest neighbors, having similar methodology and topic area.

Best papers awards and honorable mention awards are good places to start. I restrict myself to papers from the last few years, since expectations at conferences have shifted over time.

Pick a Director (or Dictator)

Every paper needs a director, and you should agree on who this will be early on. The director has a holistic perspective of what the paper should be.

The director takes input from other co-authors, allows for some discussion, but ultimately makes the final decision about what to do (in other words, the disagree and commit management strategy).

Writing Process

Science is storytelling. HCI is the science of telling stories about people.

Clarity of writing follows clarity of thought. Bullet points are easy to rearrange and refactor. But a string of incoherent words, even if there are a lot of them, is unfixable.

Writers are sometimes thought of as plotsers or pantsters, at the extremes. I’m a plotster, so it’s useful if we can nail down an outline of what we want to say for each section and paragraph before we write it.

I do all of my writing in Scrivener. I do all of my editing in other tools. Writing and editing are different processes, and require different tools. If you intermingle them, you will do neither well.

I collaborate in Overleaf. Collaborative editing is indispensible. Use track changes.

E-mail is too slow to iterate effectively. Use Slack, Skype, Google Hangouts, or nearly anything else that allows for both real-time and asynchronous group chat.

Many activities are part of the writing process, not just the words on paper: in addition to outlining, these are activities like building concept maps and annotating related work. Save these intermediate artifacts somewhere.

Make a task list and put all tasks in this central place. A task list should be easy to get to. A TASKS.md file is often good enough. Trello works too. A task list makes sure that things won’t get lost.

If all of the user studies are done, and all the data is analyzed, and there is a co-author who can deal with the figures, then historically it has taken me two weeks of focused work to prepare a paper.

Figure Rules

Figures matter, especially in HCI conferences where the figures are the only way for readers to see how users will interact with your system.

Use vector-based figures when possible. I have standardized on Figma for this workflow. Even if you’ve built a real system I will still prepare Figma mock-ups for the paper. They just look better.

Render all plots through a tikz engine (for example, matplotlib2tikz), so that they have the same font as the rest of the text. Font sizes should be consistent across all figures.

Section Rules

The Introduction should tell a single, coherent story. I use a variation of the assertion-evidence approach. The most common problem I see with Introductions are too many detours. Don’t bury the lede.

Methodology should be written as a recipe, such that another research can rerun your study process and understand why you made the choices you did. Sometimes you aren’t able to execute your recipe exactly as you wanted: save that for Limitations.

Limitations should be actual limitations. If you mitigated it, then it isn’t a limitation. As Tyrion Lannister says, “once you’ve accepted your flaws, no one can use them against you.”

Related work should not be a laundry list of papers. Related work describes how related ideas have evolved over time, and how your problem fits and differentiates from existing work (read “The Related Work Section” in Thoughts on the Structure of CS Dissertations by Spencer Rugaber).

Discussion is another tricky section. The goal of Discussion is to provide a data-inspired interpretation of the Results, through the lens of the authors. A good Discussion section provides actionability. It is not a summary of the Results.

Expect to rewrite. A lot. Sometimes from scratch. It takes me three to four days to write an Introduction, and only after many false starts. It takes me one to two days for the Discussion.

The rest of the writing I can usually do the day of the deadline if there is an existing outline that I can follow.

Style Rules

Write in plain style (sometimes called Classic Style). This is a conversational style, much like how you would speak to another academic colleague.

Show, don’t tell. Concrete examples are more important than abstact ideas. “Eat more vegetables” is concrete. The concept of “nutrition” is abstract.

People are more important than things.

Insights are more important than data.

It’s fine to use contractions: don’t, won’t, can’t.

It’s also fine—and encouraged—to use --- (em-dash) in your sentences.

But do write out: for example (instead of e.g.), that is (instead of i.e.), and with respect to (instead of w.r.t).

If it’s easier, you can write everything in active voice, and I’ll patch it to passive voice in the rare cases that it makes more sense.

Every paragraph should have a purpose. You should be able to state it. One tip is boldification (from Margaret Burnett): at the beginning of every paragraph have a comment that states what this paragraph is about.

Punctuations go inside quotes.

Footnotes go outside punctuation.

I use the Chicago Manual of Style to resolve remaining bike shedding.

Chris Parnin wrote up some Error Codes for Introductions. I agree with them.

LaTeX Rules

Use booktabs and tabularx (or tabulary) for tables. Use threeparttable where it makes sense.

Use minted for code snippets.

Use cleveref to reference figures and tables.

Use \citet{paper} to insert the author names.

Don’t hardcode participants. Make all of your participants into macros. This way you can rename or renumber them if needed.

Your document should always compile, because LaTeX error messages are cryptic and hard to debug.

Submission

I submit papers to the following conferences:

• CHI and UIST. For CHI, I pick the Engineering Interactive Systems and Technologies (EIST) subcommittee and nothing else.
• ICSE and FSE (but only if another author leads the work). I pick the closest research area to human-centered computing and nothing else.
• For early-stage work, sometimes I submit to VL/HCC because I like the smaller community and know it well.

Confusingly, the goal of picking a subcommittee or research area is to route your paper to appropriate reviewers in your community. It is not intended to accurately describe what your paper is about.

It takes a lot of effort to learn the norms of a community. Bouncing between different conferences (or even subcommittees) doesn’t help the paper.

FSE and ICSE are interchangeable. CHI and UIST seem interchangeable, but they have subtle differences in expectations.

I used to get away with not submitting the optional video, but now it appears that they are effectively required. I use Camtasia.

I can only give full attention to one submission a time.

For authorship, I always list the student researchers before full-time researchers, regardless of contribution. Generally, the intern is the first author and the intern’s mentor is the last author.

As an industry researcher, I try to write about topics that have a shorter timeline to product. I appreciate theory papers, don’t have the cycles to write them.

Submission Checklist

Pilots use checklists to prevent human error, because small mistakes in aviation can compound into big problems. The same is true of papers. Inevitably, we will need to submit a paper under pressure. Here’s a checklist for that:

• Use the correct options for submission. These are: \documentclass[manuscript,review,anonymous]{acmart}. Don’t forget to anonymize the paper.
• Run spellcheck.
• Search for the the in the paper. This is my most common repeated word.
• Search for ". You probably meant `` or ''.
• Check for ?? in the paper. You are missing citations or figure references.
• Update the abstract abstract in PCS to match the abstract in paper, and make the abstract a compelling one. Reviewers will make fast decisions about whether they want to bid on your paper based on the title and an abstract.
• Check the overall paper gestalt. Scroll through every page at a distance. Does it look like a real paper?
• Check for cliffs and potholes. A cliff is something that will cause your paper to be immediately rejected (like submitting an unfinished section). A pothole is something that accumulates damage to the paper (a confusing sentence or awkward phrasing, or missing an important related work).
• Do a best-effort pass to make sure that the citations look “reasonable.” (delete New York, New York, USA). It doesn’t have to be perfect, as you can fix the remaining issues in your camera copy.
• Check citations list for correct usage of Amy J. Ko (though it would be nice if there was a general list of names to check).

References

The following materials have influenced how I write:

• The Sense of Style: The Thinking Person’s Guide to Writing in the 21st Century by Steven Pinker
• Writing Science: How to Write Papers That Get Cited and Proposals That Get Funded by Joshua Schimel
• Making Comics: Storytelling Secrets of Comics, Manga and Graphic Novels by Scott McCloud
• How to Write a Great Research Paper: Seven Simple Suggestions by Simon Peyton Jones

I don’t recommend The Elements of Style by William Strunk JR. and E.B. White. It’s outdated and much of it is based on folklore.