This is a follow-up on my previous article, where I share some thoughts on the process of writing a semester paper.

Lots of disclaimers: this is all very specific to my experience: the topic of my paper, my supervisor, my workload in others courses, etc. Also, I’m certainly in no position to give advice on mathematical writing; these are just reflections on what worked and what didn’t work for me.

On writing papers #

Here are some principles for writing mathematical papers that I tried to follow, mostly based on feedback from my supervisors. I received plenty of useful feedback, but here are the points I found the most useful:

• Top-down exposition: concretely, this meant explaining how all lemmas would come together before proving each lemma. This minimises the amount of task-switching for the reader. In addition, this helps motivate the lemmas and allows the reader to decide which parts to skip.
• Short proofs: as a rule of thumb, I tried breaking up proofs in such a way that proofs of subresults would fit on one page. To my surprise, in most cases, this was doable.
• Reducing cognitive load: a piece of feedback I received from Vivian was to try reducing the cognitive load of the reader; it’s also a major theme here. This idea really resonated with me. Concretely, this meant doing things like:
  • Restating parameters: for example, one might go “Recalling that $X = \text{definition of }X$, we obtain…” rather than “By our choice of $X$, ….”.
  • Creating indices of notation and parameters: very relevant if your proof is notation-heavy.
  • More descriptive text: rather than writing “we have” or “thus” before a computation, I tried describing which device I was using. Mentioning that you’re using, say, a union bound doesn’t take up much additional space on the page, and it makes for a better reading experience. (Also, if you’re doing analytic number theory, you need more alternatives to “we have”!)
  • Indicating what won’t be proved: in order to keep the report at a reasonable length, I had to omit the proofs of some preliminary results and avoid repeating similar arguments. I tried making this clear to the reader, so I wouldn’t leave them hanging.
• What I would have found useful: initially, I didn’t know how many details to include. If I’d try explaining all details I’d struggled with when reading the proof, the text would be too verbose! Vivian had some good advice here: aim for the level of detail you’d liked when reading it for the first time.

For future papers, I’m considering trying the following:

• Including dependency graphs: although a bit unconventional, these can be tremendously helpful for long and convoluted proofs. See e.g. my piece on dependencies.
• Commenting on dead ends: a few words about why the naïve approach fails can be very illuminating. This can help motivate the use of some very complicated tool and potentially save the reader a lot of time. While remarks on failed proof attempts can sometimes be found in the “Discussion” section of a paper, I think like they aren’t given as much attention as they deserve (an unfortunate instance of publication bias).
• Reducing cognitive load, even more: if I’d kept this in mind during the entire writing process, I think I’d done a few things differently. For further ideas on how to reduce cognitive load, I highly recommend the previously mentioned piece.

Lessons #

If I were to write a thesis or paper again, I would have done a lot differently. Here are the main changes:

• Do it in one go: it would have been much more enjoyable and efficient doing most of the semester paper within a much shorter period of time. If you’re trying to understand an involved argument, you need all the relevant notions floating around in your brain at the same time. Don’t read one lemma per week.
• Request additional feedback: if your supervisor is kind to offer additional feedback, that’s extremely valuable.
• As soon as you get it, typeset: you’ll have to do it anyway, and you might as well do it when you understand it. This also helps corroborate your understanding.
• Know when to ask for help: I wasn’t sure how long it was reasonable for me to be stuck on a particular passage before asking for help, and I know supervisors have different preferences here. Trivial fix: ask your supervisor “For how long should I be stuck before asking for help?”
• Knowing how to ask for help: at first, I’d ask questions during meetings. But I soon began emailing a list of questions to my supervisor a few days before our check-ins. That way, I think we both got more out of the meetings.
• Typesetting takes time: it seems to be a law of nature that TeX:ing always takes longer than expected. This happened as I was writing my bachelor thesis too. Despite having a pretty sophisticated NeoVim LaTeX setup with snippets, typesetting took twice as long as I expected. For future papers, I’ll probably go with Typst.