Error Codes for Paper Introductions

Years of research can be wasted by failing to write a paper introduction that convinces a reviewer to read on. Writing a great introduction could take weeks, even after years of practice. But that’s not the goal of this post. We will strive for a more simple goal:

Lessen the chance that a reviewer will go from an accepting mindset to a rejecting mindset.

In an accepting mindset, the reviewer seeks to “trust but verify”. They generally believe the argument and results described, but will verify them and hopefully point out some ways to improve the work. In a rejecting mindset, the reviewer has already decided the paper does not meet the bar for acceptance or is just not as good as all the other papers already in the accept pile. The only goal is the find the first fatal flaw, and then build a case for rejecting the paper in a review.

Here are a list of common mistakes that immediately trigger a reviewer into a rejecting mindset. The mistakes are written in the style of error codes, typically seen in system calls.

Paper Error Codes

• ELIMITEDRESEARCH— The only motivation for the work is that there has been a “lack of research” into the problem. Maybe, it is just not that interesting or important of a problem. Fix by finding a better argument. Sometimes, the best action is to halt work on this paper, and first do empirical research to demonstrate this is actually a problem. Then you have a paper that everyone can cite to motivate the work.
• EMAXHOPS— The argument has exceeded three or more hops to get to the main point. Really poor introductions could be as long as seven hops. To fix this problem, identify the components of the argument chain and reduce its length by eliminating unnecessary steps or start closer to the root problem.
• EGESTALT— The paper simply does not look like a paper. Reviewers have implicit experiences baked into their minds after seeing thousands of papers. If they glance at your paper and know something is off, then they will immediately shift into the rejecting mindset. You’d be surprised how many papers have basic errors in the first sentence. In our reading group, sometimes we do flash reviews of papers, where we only glance at the first page of the paper in 30 seconds and spot all the issues that caught our eye. You may also consider training your own deep gestalt learner.
• EUNDEFINEDTERM— The paper extensively makes uses of jargon, or heavily overloaded words like “context”. Using specialized words before defining them indicates that the argument structure is not properly structured. This can become a problem because you are likely to increase the confusion of the reader. Think of a zero knowledge reader: Simulate a reader with only basic knowledge in your field, who must consume one fact at a time. Is there ever a place where that reader would encounter something undefined? At the same time, we do not want to read the Webster dictionary. Seek balance.
• EMAXTERMS— The introduction has introduced too many specialized terms. When seven paragraphs require twenty terms to describe an idea, something is very wrong. Again, think of the zero knowledge reader, but this time, record how many terms they must hold in their head as they are reading your text. That is, what is the Halstead complexity of your text? Keep this number low, reducing the complexity of the argument if you must.
• EUNIVERSE— The introduction starts with something like, “In the beginning, there was the big bang. Now, mobile devices are becoming increasingly becoming important in today’s society. Many people use it. Bugs are bad. Debugging effort account for 99.9% of software project cost”. You generally do not need to recount the entire history of humankind or the universe when writing about your niche research problem. A kind reviewer may simply suggest that you delete it: “Paragraph 1 seems like wasted space. I feel like this is common knowledge by now, start with Paragraph 2.” But that wasted space also means you wasted time and space that could have went to making a more essential and convincing argument.
• EDOTHENLEARN — The introduction describes all the things done in paper before stating the goals or objectives: “In this paper, we built a firewall rule system and surveyed a million developers. We learned that developers made mistakes in constructing rules” Hold on, what did we want to learn and was that the best way to do that? Instead, state: “To understand how developers construct firewall rules and avoid the mistakes they made, we surveyed a million developers and then built a system that would …”. Now we can begin to ask, if we wanted to learn mistakes developers make, was a survey the best way to learn that?
• ETELLDONTSHOW — The argument relies on too many assertions made by the author that either lack backing or sufficient details for the reader to make their own judgements. For example, instead of asserting, “Automated refactoring is important. (Tell)” , try Show Don’t Tell: “In contrast to automated refactoring tools, a number of studies [1–3] show that developers routinely make mistakes when conducting manual refactoring operations. (Show)”. The reader can now decide for themselves whether automated refactoring tools might be important based on the evidence of mistakes without automation.

Other error codes related to argument structure or miscellaneous issues:

• EBADARGUMENT—There is a fatal premise or missing link in the argument chain.
• ENOPROBLEM— There is no problem described.
• ESOWHAT— What are we supposed to do as a result of your study?
• EUNQUANTIFIABLE— Using “deeper” or “better” in argument. How is something “better”?
• EZEROCITES— The paper lacks any references to the conference/journal being submitted to. Do the authors know the field? Is this a good fit to the conference?
• ENOEXAMPLE—There is no concrete examples to be found anywhere. Everything is abstract and vague.

Next time you write an introduction, check it for these error codes, and keep the reviewer in the accepting mindset!