The document provides advice on the process of writing research papers. It recommends starting early and collaborating with others. Reviewers should be treated as providing helpful feedback to improve the paper. The writing should use clear, direct language and provide structure and examples to enhance readability. Technical details or weak results may be relegated to appendices or technical reports to focus on the key contributions in the paper.

1. How to Write Research Papers Part 2 – The Process of Writing Xiao Qin Department of Computer Science and Software Engineering Auburn University http://www.eng.auburn.edu/~xqin [email_address] These slides are adapted from notes by Simon Peyton Jones (Microsoft Research, Cambridge)

2. The process Start early. Very early. Hastily-written papers get rejected. Papers are like wine: they need time to mature Collaborate Use CVS to support collaboration

3. Getting help Experts are good Non-experts are also very good Each reader can only read your paper for the first time once! So use them carefully Explain carefully what you want (“I got lost here” is much more important than “Jarva is mis-spelt”.) Get your paper read by as many friendly guinea pigs as possible

4. Getting expert help A good plan: when you think you are done, send the draft to the competition saying “could you help me ensure that I describe your work fairly?”. Often they will respond with helpful critique (they are interested in the area) They are likely to be your referees anyway, so getting their comments or criticism up front is Jolly Good.

5. Listening to your reviewers This is really, really, really hard But it’s really, really, really, really, really, really, really, really, really, really important Treat every review like gold dust Be (truly) grateful for criticism as well as praise

6. Listening to your reviewers Read every criticism as a positive suggestion for something you could explain more clearly DO NOT respond “you stupid person, I meant X”. Fix the paper so that X is apparent even to the stupidest reader. Thank them warmly. They have given up their time for you.

7. Language and style These slides are adapted from notes by Simon Peyton Jones (Microsoft Research, Cambridge) Xiao Qin Auburn University http://www.eng.auburn.edu/~xqin [email_address]

8. Basic stuff Submit by the deadline Keep to the length restrictions Do not narrow the margins Do not use 6pt font On occasion, supply supporting evidence (e.g. experimental data, or a written-out proof) in an appendix Always use a spell checker

9. Visual structure Give strong visual structure to your paper using sections and sub-sections bullets italics laid-out code Find out how to draw pictures, and use them

10. Visual structure

11. Use the active voice The passive voice is “respectable” but it DEADENS your paper. Avoid it at all costs. “ We” = you and the reader “ We” = the authors “ You” = the reader NO YES It can be seen that... We can see that... 34 tests were run We ran 34 tests These properties were thought desirable We wanted to retain these properties It might be thought that this would be a type error You might think this would be a type error

12. Use simple, direct language NO YES The object under study was displaced horizontally The ball moved sideways On an annual basis Yearly Endeavour to ascertain Find out It could be considered that the speed of storage reclamation left something to be desired The garbage collector was really slow

13. Summary If you remember nothing else: Identify your key idea Make your contributions explicit Use examples A good starting point: “ Advice on Research and Writing” http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/ mleone/web/how-to.html

14. How to Write Papers Dr. Xiao Qin Auburn University http://www.eng.auburn.edu/~xqin [email_address] These slides are adapted from notes by Dr. Nitin Vaidya (UIUC)

15. How to write a paper When you have truly exceptional results. Probably doesn’t matter how you write, people will read it anyway Most papers are not that exceptional Good writing makes significant difference Better to say little clearly, than saying too much unclearly

16. Readability If the paper is not readable, author has not given writing sufficient thought Two kinds of referees If I cannot understand the paper, it is the writer’s fault If I cannot understand the paper, I cannot reject it Don’t take chances. Write the paper well. Badly written papers typically do not get read

17. Do not irritate the reader No one is impressed anymore by Greek symbols Define notation before use If you use much notation, make it easy to find summarize most notation in one place

19. Do not irritate the reader Avoid Using Too Many Acronyms AUTMA ?! To save space? Guarantee Ratio or GR You may know the acronyms well. Do not assume that the reader does (or cares to)

20. How to write a theory paper Unreadability is not the same as formalism Reader should be able to understand contributions without reading all details If some proofs are not too important, relegate them to an appendix Proofs are not as worthy as new proof techniques

21. How to write a theory paper If some proofs are not too important, relegate them to an appendix [Ref] Response time analysis of parallel computer and storage systems-IEEE TPDS2001 Before references

22. How to write a systems paper Provide sufficient information to allow people to reproduce your results people may want to reproduce exciting results do not assume this won’t happen to your paper besides, referees expect the information Do not provide wrong information Sometimes hard to provide all details in available space may be forced to omit some information judge what is most essential to the experiments cite a tech report for more information Provide source code

23. Discuss related work Explain how your work relates to state of the art Summarize pros and cons of existing approaches Discuss relevant past work by other people too Remember, they may be reviewing your paper. Avoid: The scheme presented by Qin performs terribly Prefer: The scheme by Qin does not perform as well in scenario X as it does in scenario Y Avoid offending people, unless you must

24. Tell them your shortcomings If your ideas do not work well in some interesting scenarios, Tell readers Explain why the ideas do not work well May point out how to improve People appreciate a balanced presentation

25. How to write weak results If results are not that great, come up with better ones Do not hide weak results behind bad writing Be sure to explain why results are weaker than you expected If you must publish: write well, but may have to go to second-best conference Only a few conferences in any area are worth publishing in Too many papers in poor conferences bad for your reputation Just because a conference is “IEEE” or “ACM” or “International” does not mean it is any good If results not good enough for a decent conference, rethink your problem/solution

26. Miscellaneous Read some well-written papers award-winning papers from conferences organization Avoid long sentences If you have nothing to say, say nothing don’t feel obliged to fill up space with useless text if you must fill all available space, use more line spacing, greater margins, bigger font, bigger figures

27. Technical reports Useful to get early feedback from other researchers Puts a timestamp on your work Can include more information / results than might fit in a paper

28. Download the slides from A good starting point: “ Advice on Research and Writing” http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/ mleone/web/how-to.html http://www.slideshare.net/xqin74/how-to-write-papers-part-1-principles

29. http://www.slideshare.net/xqin74 Google: slideshare Xiao Qin

30. Questions