Organise the paper

I have always found that plans are useless, but planning is indispensable. (Dwight Eisenhower, quoted in “Six crises”)

Some thought should be given as to the logical layout of the paper; a stream-of-consciousness format, in which results are presented in the order in which they occurred to the author, are generally a very bad idea, as they project an image of carelessness and are hard to follow (or enjoy) by readers or referees.

For instance, peripheral results which are not strictly necessary to the main argument should be moved to remarks, footnotes or discussion sections.

Results which are necessary to the main argument, but which are very different in nature from the rest of the paper (e.g. they use material from a different field of mathematics, or consist entirely of dull computations), may be placed in an appendix.

Each time there is a major turning point in the argument, or a shift to a different component of the argument, one should start a new section; conversely, a collection of closely related facts should probably be placed within a single section.

Whenever possible, each major milestone in the argument should be formalized in a self-contained and prominently located proposition or theorem, in order to facilitate a “high-level” understanding of the argument, and to allow the reader to mentally divide the argument into simpler non-interacting components. (See also “[Create lemmas](“Create lemmas”).) Generally speaking, readability is improved if these milestones are placed relatively early in the paper (and, in particular, before all the technical details involved in the proof of that milestone have appeared yet), so that the reader has some idea what is going on during the reading process. (Papers in which the punch line is delayed until the very last page of the argument, when finally all the dozens of mysterious and technical pieces of mathematics developed throughout the paper are finally assembled to do something useful, tend to be particularly frustrating to read, as the “big picture” will be absent for almost all of the paper.) See also “[motivate the paper](“motivate the paper”).

Try to group related sections together; thus for instance, the statement and proof of lemma X should ideally be placed close to where lemma X is actually used (especially if the lemma is only used once in the entire paper).

As a general rule, the more technical components of the paper should be pushed to the back of the paper if possible, in order to ease the “learning curve” for the reader. When the reader is near the front of the paper, he or she will not yet be fully comfortable with your notational conventions and techniques, and so it is best to “reward” him or her with some relatively easy and tangible progress towards the main results; by the end of the paper, the reader will have more of an idea what is going on, and will be more capable of handling the more difficult parts of the paper.

Of course, executing all of these suggestions may require some initial planning and thought, and possibly some significant reshuffling of the paper from its first draft, but with modern text editors (and especially with LaTeX, which has automatic theorem numbering and similar tools to facilitate this reshuffling) this is not as difficult as it used to be, and it does significantly increase the readability (and hence influence) of your paper.

When reorganising a particularly large and complex paper, it is sometimes helpful to diagram the logic of the paper. One way to do this is to take the largest blackboard one can find, and draw a box for each lemma or theorem, and an arrow for each logical deduction (e.g. if Theorem 13 uses Lemma 4 and Lemma 7, draw arrows from the Lemma 4 and Lemma 7 box to the Theorem 13 box. A blackboard is better than paper for this due to the ability to erase and redraw to move boxes and arrows around.) By doing so, one should be able to spot the key milestones in the paper, and which lemmas will naturally group into sections or appendices.

I find that organising a paper also becomes easier if you first write a rapid prototype.