More Tips from Charles Leiserson to Write Scientific Papers

I learned more from Charles Leiserson about writing scientific papers and doing presentations. The focus here is on diagrams, figures, codes, and other artifacts.
Here are a summary of my observations from his today's workshop:

• Shade foreground in diagrams with some light color. This directs attention to the right place. Sometimes (rarely) use shadows in diagrams (shadows are good for PowerPoint slides). This helps in terms of "emotional impact" on reviewers (e.g., no typos, not polished, etc.)
• Avoid clutter on axis (e.g., instead of having multiple "*10×6", replace with "in millions").
• Place data description close to data (e.g., replace legends with labels on the side of plotted function). 
• Try to change diagrammed functions in a way to have less compaction and make them more readable (e.g., normalizing them). 
• It is good to have a summary plot in the introduction and add breakdowns (with more details) later.
• Have full sentences in the caption of figures (it is good to have a phrase at the beginning and continue with full sentences). The phrase is semantic and the following sentences are syntactic aspects about figure. In the body of the text, you do not talk about syntactic aspects. Similarly, arguments that belong to the text should not be in functions. Don't be repetitive.
  One other way is to say: "X is better than Y" (semantic part, the takeaway, the message, ...), followed by syntax description. 
• Colors: they should enhance the figure; yet, the figure should be understandable for people who are color-blind or have a printed copy in black and white.
• Be careful when presenting a diagram in terms of a continuous curve; it might raise questions when your data points are discrete (in that case, make sure the data points are highlighted using 'dots' in the diagram). Also, consider using bar-charts when applicable (sometimes continuity should be highlighted with using curves instead of charts).
• You should always have one exhibit in the introduction as an executive summary (a diagram, a figure, a table, etc.). Work-examples are good also for Introduction to motivate.
• Tables: generally, avoid vertical line and horizontal lines (unless needed, e.g., the first row). First column is left-justified and others should be center-justified. Consider using "siunitx LaTex package".  Headers should be italic and body in roman.  Make sure that the semantic is included at the beginning. 
• Captions should include a small semantic sentence/phrase, followed by syntactic sentences. It should not include more semantic descriptions/conclusions. They go to the text. Syntactic sentences should be precise. 
• No colons in the first column of table; in slowdowns, don't use 'x', remove 'test name', transpose tables in a way numbers that you compare are vertically aligned: stuff in the same column should be comparable (as opposed to rows). Include more data in necessary (e.g., include both running time and slowdown, it is better to have division of two rows if required (e.g., slowdown).
• It is good to downsize caption compared to body text. Size of the caption should be uniform with the text in figures. There are exceptions, e.g., axis labels. This requires avoiding shrinking of figures -which makes figure labels smaller-.
• In your figures, use alignment (e.g., in PowerPoint) so that figures are symmetric whenever required (e.g., boxes should have the same size and their edges should be aligned in a figure). 
•  Be careful when using examples, e.g., when drawing a triangle, if you draw it with equal sizes, the reader easily generalizes it to all triangles in the text (while you might mean a general triangle).
• For graphs, consider placing arrows on the middle of the edges instead of endpoints (in order to avoid congestion on vertices). This is done in "Combinatorial Mathematics".
• Always use a face in a diagram if possible (e.g., a student in a diagram can be presented by a face of body). This will be more compelling for the reader. This point applies definitely to presentations and, to some extent, to papers. 
• It is not bad to be entertaining when writing your paper. It is OK, as long as it is not distracting. 
• Use Inconsolata font for including code and other situations which require  fixed-width font in your paper. It is also good to put code in a box which is highlighted (with a little triangle on the bottom-right, which gives a feeling that the code is inside a sheet).  Also, in case of a code, colorize it (see this paper, for example). Avoid using black font in the code; replace it dark-dark brown, and apply the same when using words from the code in the text (e.g., "we do X to implement 'for' loops").
• In papers, consider numbering code-lines globally. 
• Avoid possessive terms such "our software", "our result", etc. It sets up a dynamic with the reader which is not very nice.  Do not have too much dependency on using "we" and "our" in general.