This article targets technical computer science papers that aim to introduce new contributions. If you are writing something else (e.g., a technical blog post), these tips may or may not apply.

Know your audience. Envision a community you want to sell your ideas to. Know what people know and what people don’t know. Know what people want to know.

Start early. Ideally, start as soon as you have a research idea. Draft down why your idea makes sense, what is your idea, and what is your plan. Iterate your writing over a long time (months or even years).

Get to the point fast. Ideally, you want your audience to have a brief idea of what they are going to learn in 30 seconds as soon as they start reading (think of an elevator pitch). The first paragraph of a paper is the most important paragraph. If you waste one minute of each reader’s time and you have 1000 readers, you waste 1000 minutes in total (sorry for being a typical Asian teacher).

Always start with “why” before “what” and “how”. Ask “why” to every single sentence you write, and prepend the reason before the sentence. Naturally, this forms a “top-down” structure of your piece starts from the biggest motivation. One way is to start by writing: “I want to achieve X”, “but it’s hard because of the challenge(s) Y”, “therefore we do Z to address the challenge Y”. You can then apply a recursive algorithm to expand your writing and clarify: Why do you want to achieve X? Why is the challenge Y hard? Why does Z solve the challenge Y? What doesn’t Z solve? The entire paper should be a fractal hierarchical structure of these questions and answers. (Now, practice this: how would you rewrite this paragraph to include the “why”? Why is it better than the current version?)

Sort your points by their importance. Rank from high-level ideas to low-level details. Avoid dumping implementation and mathematical details early on in the paper.

The criteria of a good research project are: 1) do people care about it? 2) does it involve non-trivial unsolved challenges? 3) does your solution demonstrates intellectual insights? 4) is your solution sufficiently different from alternatives? 5) can you show both theoretically and empirically that your solution convincingly solve the non-trivial challenges? 6) can you show both theoretically and empirically that alternative solutions do not convincingly solve the non-trivial challenges? Address all these points explicitly and spoon-feed them to your readers.

Strives for conciseness: for every section, ask yourself what the section is going to achieve, and if it is relevant to what you want to teach the audience in this article. Even if it is a useful knowledge, ask yourself whether it is the most effective to say it in this article, or you should write a separate article about it. Replace “section” with “subsection”, “paragraph”, “sentence”, “phrase”, and “word”. Check for redundancy throughout the paper: do I need to repeat the same thing multiple times? (Sometimes repetition is a good thing.)

A picture is worth a thousand words. Make illustrations and figures first, and plan your narrative around the figures. Treat the figures like how you would explain your idea to someone else on a whiteboard. Ideally, a paper should be readable by reading the figures and the captions alone.

When making figures, legibility is key: focus on clarity of presentation, instead of prettiness. Can I represent the same thing in 1D instead of 2D? Can I represent the same thing in black-and-white instead of in color? (Think of color-blind people.) Is everything still legible after printing out physically? (Believe it or not, people still print out papers to read them.) Once you have aced legibility and clarity, you can start aim for prettiness if it does not sacrifice clarity.

In the results, academics are often looking for “surprises”. What works unexpectedly well/bad? Can we explain them?

Treat your collaborators as potential readers. If they don’t like certain part of the paper, that means many of your readers will not like those parts too. You will get conflicting opinions from your collaborators. Try to find the best middle ground, but you also sometimes have to make a opinionated choice. Never simply ignore the comments from your collaborators.

Be nice to prior works like how you would like other people treat your works. Read them deeply and emulate what the authors are thinking. Always err on the generous side.

Avoid acronyms at all cost. “We apply MIS to BDPT using the PDF of BSDFs and NEE to reduce MSE when solving RE in GD.” Acronyms makes reading hard and doesn’t save you much space. Just spell them out.

Make sure your paper is still completely readable without mathematical equations and (pseudo)code.

Avoid words that make you sound smart and pretentious: “utilize” (use), “leverage” (use), “framework” (method), “paradigm” (method).

Break down long sentences. For every comma you see, ask yourself if you can break it into two sentences.

Cleanup your biblography. Pay respect to the authors/venues/journals, just like how you would want other people to pay respect to you.

Once you have aced all of above (which is very hard), maybe start thinking about adding a little bit of “style” to make reading your paper more interesting. Write something unexpected but reasonable. Surprise your readers.

Some resources: Fredo Durand, Notes on writing https://people.csail.mit.edu/fredo/PUBLI/writing.pdf Simon Peyton Jones, How to Write a Great Research Paper https://simon.peytonjones.org/great-research-paper/ Bill Freeman, How to write papers and give talks http://6.869.csail.mit.edu/sp21/lectures/L22/freeman.pdf Wojciech Jarosz, Common mistakes in technical writing https://cs.dartmouth.edu/~wjarosz/writing.md.html David Salesin, How to write a SIGGRAPH paper https://vitalight.me/upload/2021/03/RE00-How-to-Write-a-SIGGRAPH-Paper-7e2a071d1fa64145bdba16fee093aca7.pdf Li-Yi Wei, How to write a SIGGRAPH Paper https://www.liyiwei.org/courses/how-siga11/liyiwei.pptx