These are some guidelines that I compiled, mostly lifted from Tom Cormen’s Technical Writing in CS class and compiled from mistakes that I previously made.
General writing tips
- The first sentence in a paragraph should tell me what that paragraph is about.
- Use verbs instead of gerunds when possible (the inclusion of -> including).
- Use active voice.
- New information should come later in the sentence (or table).
- Feel free to be creative, even in academic writing (my own opinion).
- The worst place to use however is at the beginning of a sentence. -Tom Cormen
- Don’t use while when you mean although or whereas.
- Use compute instead of calculate.
- You can use the word shall to sound fancy.
- Consider replacing so with and so. -Tom Cormen
General paper tips
- Take elements from top conference papers that you like and try to incorporate them into your own paper, if applicable.
- Absolutely do not overstate the novelty of your paper. Good reviewers will notice.
- Try a creative title. I should not get tired when I read it. Tom Cormen suggests titles like ‘Algol 68 with Fewer Tears’, ‘ViC*: Running out-of-memory instead of running out of memory”, ‘50 shades of grey codes’.
- Your literature review be comprehensive and include all relevant papers and well-known papers in the area. Don’t get rejected because you were too lazy to do a good literature review.
- Include math if relevant.
- Make sure your paper is exactly the page limit and not a single line less. Some tricks for saving space: delete spacing between figures and their captions, make the font and cell padding in tables smaller.
- If your paper isn’t at the page limit, this could be an indicator that you should do more experiments.
- You should make your code and data available, if possible.
- All your references should have links. (Otherwise, how am I supposed to find it? -Tom Cormen)
- After you finish your first draft, go through the entire paper and delete any unncessary words. Also check all the prepositions to make sure they’re correct.
- I suggest listing your specific contribution(s) in the introduction of the paper. It doesn’t seem like a big deal when it is there, but if a reviewer has a hard time following your paper and figuring out what the main contribution is, that’s a big problem.
Figures and tables
- Include a pull figure on the first page to give the reader an idea of what the paper will be about.
- Your font is too small.
- Your tables should not have more lines (e.g., borders), than necessary.
- Should some tables be represented as graphs?
- For a multivariate function z = f(x, y), consider using a heatmap. They look colorful.
Jason’s list of nicely used words
- I had used all the tricks in my “how to look like an adult” arsenal. -My brother
- He could not marshall any evidence to support his argument. -Sam Harris
- That is not a surrogate to the wise use of government resources.
- One can easily be seduced into thinking that CGT can immediately deliver similar breakthroughs. -George Cybenko
- Augmented examples dominate the training distribution. -Me
- Accepting that original and augmented distributions might differ liberates us to apply stronger levels of data augmentation. -Me
- From A Tale of a Probe and a Parser
- This begs the question:
- It has nothing to do with model complexity and appears orthogonal to the goal of a probe.
- We contend that…, we advocate for the position that
- Justifying metric choice is of central importance for probing, lest we muddy the waters with a preponderance of ill-understood metrics.
- This process ought not to be conflated with the analysis of a particular model.
- The line between what constitues a probe or a model is awfully thin.
Tips specific to applied ML/DL papers in medical journals
- It is good to have baseline approaches for comparison, even if the point of your paper isn’t the methods. This came up a lot in reviewer comments for me when I didn’t include it.
- For methods papers, you should have a table comparing your results with other those from papers for a given benchmark task. You should also validate on multiple datasets.
- If your test set is small, are you overfitting?
- If you’re presenting a new application of deep learning, do some error analysis. What is your model doing well and what isn’t it?
- What’s the training time and runtime of your model?
- Can you do a cute visualization like t-SNE?
- It’s often nice to have a table that summarizes the dataset(s) you are using. This is a must if you’re using a novel dataset. Maybe try a violin plot.
- For vision applications, it’s nice to have some LIME/CAM visualization to see what your model is looking at.
- You can display a confusion matrix as a heatmap.
- For multi-class precision/recall/f1 tables, try a plot like in Figure 3B here.
- Include ROC and AUC if applicable, and show the point on the curve that the model is performing at.
- Some reviewers will suggest rejection if there is no methodological innovation.