Writing is not just something that happens at when the research is “done”; rather, writing should occur throughout the course of a research project. Writing and thinking are tightly coupled—writing is a reflection of our own thoughts, and writing well can actually sometimes clarify our own thinking about a problem and lead us to a solution. An attempt to write down a concept, idea, or solution can actually help you realize that you don’t know what you are talking about! (And, help you crystallize your thinking.) You may have had the experience of realizing you don’t understand something as well as you thought you did when someone asks you to explain something and you have trouble. Writing achieves the same effect: as you attempt to write something down, you may realize that you don’t know why you are working on something, why a particular phenomenon appears, and so forth. If you don’t force yourself to try to write down your explanations and observations, you may never discover that you don’t know what you’re doing until it’s too late. Therefore, start writing early in the course of a research project. Most of the early text you write may not find its way into the final version of the paper, but taking the time to express your ideas on paper can help you crystallize your thoughts and guide your research.
- Don’t wait: write
- Identify your key idea
- Tell a story
- Nail your contributions
- Related work: later
- Put your readers first (examples)
- Listen to your readers
For a given research result, there are many stories that a paper could tell, and it’s important to think about what the story should be. This decision should be made early on in the writing process. The story can be changed later on, to match the strongest results in the paper, or if the context for the research changes (for example, sometimes when working on a research problem, people can find it necessary to re-formulate the problem that they are solving). But, it’s always good to figure out a story before you go too far down the path.
Determining the Big Picture: Composition and “Flow”. Composition is the structure and flow of your paper writeup, and how individual paragraphs fit together. When people talk about the “flow” of a piece of writing, they are talking about composition: how sentences flow together to form paragraphs, how paragraphs flow together to form sections, and how sections flow together to form a paper. Composition (or “flow”) is the most important aspect of technical writing. I’ve found that reviewers (and readers) are often forgiving of the occasional grammatical error, especially if a paper was written by non-native English speakers. The human brain is pretty good at applying “error correction” on grammar. Correcting “flow”, on the other hand, is extremely hard for a reader to do. Often, the reader will complain that they “can’t understand where [the paper] is going” and simply give up. Grammar is also easier to teach (and learn) than composition because there are fixed rules for grammar; composition is more of an art form, and it does involve a bit of intuition. It involves thinking about the big picture, the story that you want to tell, and how the pieces fit together. It takes practice to develop intuition for composition, and I’ve found that native English speakers are not necessarily any better at composition than foreigners are (that’s good news for Ph.D. students coming from abroad: the playing field is actually more level than it appears).
Write sections and topic sentences first. There is always the temptation to simply jump in and start writing full paragraphs. This rarely ends well. Nobody would build a house before first drawing plans. After the plans comes a foundation, and scaffolding. Only after the structure is in place can many of the details be filled in. You should think about writing a paper in the same way: before you can fill in the details, you need to figure out how you want the paper to read when its done; this is your outline. Start at a high level, by outlining sections. Once you have an outline of sections, you can begin to slowly fill in more details: outline each paragraph within a section by writing only the topic sentence for the paragraph. See whether your story makes sense if you read each topic sentence in sequence. Your “paper” should roughly make sense if you read these topic sentences in sequence (in fact, some reviewers or readers may try to read your paper in exactly this fashion, by skimming topic sentences!). If reading your topic sentences in sequence doesn’t make sense, something is wrong with your flow. Determining which topic sentences to write takes a bit of practice, but I find that making a bulleted list of points that you want to include in the section and then clustering those points into related points and topics can help identify the topics you want to cover (and, hence, the topic sentences you want to write). If you find that the topics you want to cover are not all related to one another, you may need to create additional subsections. Once you have topic sentences, you can fill in paragraphs, which are groups of closely (and logically) related sentences. If your sentences aren’t closely related, they don’t belong in the same paragraph and you may need to consider adding a new topic (and topic sentence).
- Here is a problem
- It’s an interesting problem
- It’s an unsolved problem
- Here is my idea
- My idea works (details, data)
- Here’s how my idea compares to other people’s approaches
- Title (1000 readers)
- Abstract (4 sentences, 100 readers)
- Introduction (1 page, 100 readers)
- The problem (1 page, 10 readers)
- My idea (2 pages, 10 readers)
- The details (5 pages, 3 readers)
- Related work (1-2 pages, 10 readers)
- Conclusions and further work (0.5 pages)
Write the introduction first—and last. I typically try (and encourage students) to write a draft of the paper's introduction before writing other parts of the paper. You will most likely eventually discard this draft completely, since it's very hard to predict what one should be emphasizing in the introduction before the “meat” of the paper is done. Yet, writing an early introduction draft allows a researcher to put the work in context, and to argue (1) what the problem is, (2) why it is hard, and (3) why the solution (if it is achieved) will be interesting to readers. If an introduction draft can't articulate answers to these questions, even at an early stage in the research, then the work likely needs some focus, as well. When you write the second version of your introduction (after the rest of the paper is written), you are in a good position to refine your story, making sure that any claims you make are clearly supported by your results and data. Your results should be stated as clearly and specifically as possible. You should neither understate your results (which might cause the reader to lose interest and stop reading) or overstate them (which might cause the reader to be annoyed or “let down” when they dig in and find that you don’t deliver on what you've promised).
- Write the list of contributions first
- The list of contributions drives the entire paper: the paper substantiates the claims you have made.
- Reader thinks “gosh, if they can really deliver this, that’s be exciting; I’d better read on”
Signpost your paper. Even if your paper plan and outline make perfect sense to you, the reader doesn’t start out “on the same page” as you. Even if the builders have built a house completely according to the blueprints, even if the design of the house follows convention, visitors still typically appreciate an explanation of where the bathroom is. The reader needs instructions for how to read the paper and a clear view for how the paper and story will proceed. Signposts throughout the paper help the reader understand how the paper is organized. Examples of signposts include: an outline of the paper at the end of the introduction (“The rest of this paper proceeds as follows.”), a preamble to each section (“In this section, we discuss…”), declarative subsection titles, and (within reason) bold paragraph headings (such as those in this blog post).
-
We give the syntax and semantics of a language that supports concurrent processes (Section 3). Its innovative features are...
-
We prove that the type system is sound, and that type checking is decidable (Section 4)
-
We have built a GUI toolkit in WizWoz, and used it to implement a text editor (Section 5). The result is half the length of the Java version.
No “rest of this paper is...”!!!
Your introduction makes claims. The body of the paper provides evidence to support each claim. Check each claim in the introduction, identify the evidence, and forward-reference it from the claim.“Evidence” can be: analysis and comparison, theorems, measurements, case studies
Do not recapitulate your personal journey of discovery. This route may be soaked with your blood, but that is not interesting to the reader. Instead, choose the most direct route to the idea.
- Explain it as if you were speaking to someone using a whiteboard. Introduce the problem, and your idea, using EXAMPLES and only then present the general case.
- Conveying the intuition is primary, not secondary
- Once your reader has the intuition, she can follow the details (but not vice versa)
- Even if she skips the details, she still takes away something valuable
A good plan: when you think you are done, send the draft to the competition saying “could you help me ensure that I describe your work fairly?”.
Often they will respond with helpful critique (they are interested in the area)
They are likely to be your referees anyway, so getting their comments or criticism up front is Jolly Good.
Reading long installments of technical writing is tiring, and seeing a page of uninterrupted technical writing can psychologically tire the reader before they even begin to read. Create whitespace and take other steps to break up large chunks of text. Use paragraph headings to break up long strings of text (ensuring that your headings match the topics you’ve outlined, of course). Try to space figures, tables, and graphs throughout the paper so that most pages have a mix of figures and text. If you don’t have a figure to break up the text, consider making one. Often, a table summarizing results can be useful. Or, you might find that a figure (or block of pseudocode) describes a concept better than a paragraph in your writeup. Take steps to ensure that your writeup is not a long stream of text.
Section headings at the bottoms of columns or pages look sloppy. Depending on your word-processing tool, there are good ways to get rid of widows. In Latex, you can always use a “\vfill” to kick the section heading to the top of the next column. Similarly, widows on paragraphs (paragraphs that end with a single word on the last line) look sloppy. Typically you can eliminate such widows by wordsmithing (see below on omitting needless words). Latex also has macros such as “\widowpenalty” that help ensure that the text layout avoids widows whenever possible.
If you’ve edited your text down to remove redundancy, you may find that you have some extra space at the end of your paper. Try to adjust your formatting so that the last page of the paper looks decent. If your paper is double-column and you end with references, balance the references across the two columns so that both columns are both equally (partially) filled. Latex has a “\balance” command that you can use to balance the columns on the last page of your writeup. If you have a bit more time, you can also make small adjustments to margins, space between columns, space around figures, sizes of figures, and so forth to ensure that the last page doesn’t look like you just suddenly decided to stop writing.
The easier it is to read your paper, the more likely a reader will keep reading. Therefore, don’t make the reader work harder than they have to. On a sentence level, follow Strunk and White’s most indispensable advice: Omit needless words (e.g., “to” as opposed to “in order to”, “optimizing” instead of “the problem of optimizing”, “This module…” instead of “This is a module that”, “more quickly” instead of “in a shorter time”, “whether” instead of “the question as to whether”). Avoid padding phrases such as “the fact that” and unnecessary adverbs (e.g., “eliminated” instead of “totally eliminated”, “fast” instead of “very fast”). Keep words simple (e.g., “use” instead of “utilize”, “new” instead of “novel”), and keep sentences short.
Always make at least one (and probably several) editing passes over your paper to cut out redundancy. You likely (and hopefully) did not write your paper in a linear fashion, and different co-authors may have written different sections or pieces of the paper. It’s likely that you’ve stated the same point multiple times throughout the paper. Cutting redundancy takes practice, and it sometimes requires divorcing the editing process from your ego (after all, isn’t that sentence you wrote beautiful? It’d be a shame to cut it, right?). If you need help cutting, ask someone else (a co-author or colleague) to help you—they’re not as married to your text as you are.
Precision is especially important when describing results, and when writing up an experiment or evaluation section. For example, a good rule of thumb for writing up an evaluation section is: Would someone be able to reproduce your experiment from your description? If not, you need to be more clear. In an evaluation section, clearly state your assumptions; in what context(s) do your results hold? How general are they? Clearly describe your evaluation setup, as it sets the context for the results themselves. What machines did you use to run the evaluation? What data did you gather to support your conclusions? What algorithms did you use to analyze the data? The evaluation setup should read like a recipe. Someone reading it should be able to reproduce what you’ve done, at least well enough to understand the context of the results. Similarly, the results should be clearly and precisely described. Avoid writing sentences such as “This optimization significantly reduced the system’s running time.” Such vague statements frustrate the reader. Instead, substitute precise and specific information: “This optimization reduced the system’s running time by 20%”.
[1] https://greatresearch.org/2013/10/11/storytelling-101-writing-tips-for-academics/
[2] https://www.microsoft.com/en-us/research/academic-program/write-great-research-paper/
[3] https://press.uchicago.edu/ucp/books/book/chicago/C/bo23521678.html
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent