06-How-to-Write-and-Present.Rmd

# How to Write 


## Five Common Writing Mistakes


The following is heavily based on a blog-post of [Jacquelyn Gill](https://contemplativemammoth.com/2018/08/21/five-common-writing-mistakes-new-scientists-make/). 


**1. The passive voice is being used.** <br>
This is an understandable mistake, because not only are we taught to write passively in primary and secondary school science classes, but many of my colleagues still cling to the idea that solid, objective scientific writing must be in the passive voice. However, the passive voice ...

  * results in unnecessarily long sentences and   
  * makes your prose difficult to follow.  


Why is the active voice better? Because science is an active process, done by human beings: "I" and "we" statements are appropriate when describing action. For instance, "We demonstrate the usefulness of our method" is much nicer to read than "The usefulness of the method is demonstrated". The active voice is more engaging to read by its very nature, which makes otherwise dry methods sections just a bit less tedious. We are a storytelling species -- we like a little drama! 


\



**2. Extraneous, superfluous or otherwise unnecessary additions.** <br>
*Example of bad writting:* It is entirely likely that your prose is padded with extraneous, superfluous, or otherwise unnecessary additions; furthermore, the utilization of such redundant verbiage is arguably obfuscating your points (thus, in order to improve the clarity of your writing, it is highly recommended that you eschew such stylistic choices, including run-on sentences filled with fluff, padding, and filler). 


Perhaps a consequence of assigning papers with word counts, text padding is one of the most common issues with student writing, especially for those writing their first manuscripts. My example sentence above has a few issues: 

1. Double (or triple)-dipping with adjectives when one would do
2. It crams too much, abusing semi-colons and parentheses for useless purposes
3. It's full of "junk" phrases that serve no purpose whatsoever. 


    
Tips:    

* "In order to" is not necessary when "to" will do. 
* "It is entirely likely that" can be replaced with a single word (likely): "Your prose is likely..." 
* Words like "arguably" or "furthermore" or "thus" rarely do any heavy lifting in sentences, and are often implied anyway. 
* "Highly" isn't needed in front of "likely."
* "Utilize" is rarely more appropriate than "use."




How to avoid unnecessary additions:

* Relentlessly go over your prose to **remove junk**. 
* When you're over your word count on an abstract or conclusion section, look to cut sentence padding first, before you start cutting your cool ideas.
* Take opportunities to be creative, but not at the expense of clarity.


People often assume the thesaurus will help them sound smarter, but instead leaves your reader thinking, "wow, she/he really loves her/his thesaurus." Use fun words sparingly, and **aim for clarity**. 


\


**3. Your prose contains redundant parts.**<br> 
You keep making the same point over and over again. I often find myself reading prose that has the same idea presented in multiple ways -- sometimes word for word, from one paragraph to the next! Regardless of how this happens, redundancy highlights the importance of taking a break from your work. Redundancy is also usually a symptom of poor organization; a lack of structure can lead to circular writing, because you don't know where you've come from and you don't have a clear sense of where you're going.


How to avoid redundancies:

* If you’re revising your own work, you should be catching the places of redundant text parts. 
* Reading your writing out loud helps (you're more likely to catch errors than if you skim the page reading to yourself).
* Get comfortable with deleting your writing. Cutting words/texts is part of the writing process, and sometimes it’s the most effective way to make your writing better. That doesn’t mean the initial writing was wasted -- it’s all part of what got you to cleaner, stronger prose.


<!-- Best tip: don’t write redundant text.  -->

\


**4. Unclear antecedents.** <br> 
When you find yourself writing "this," check to make sure that "this" is clearly linked to an antecedent. Remember that your readers aren’t in your head, and the connections may not be intuitive. In scientific writing, this problem (haha, see what I did there?) often happens in the beginning of sentences and paragraphs. "This is a problem, because..." What's the problem? 


\


**5. Your paragraph lacks of a topic sentence.** <br> 
Each paragraph should have a topic sentence anticipating the main message of the paragraph. Topic sentences help your reader to follow your writing. Furthermore, topic sentences are useful to diagnose structural problems in writing. The sequence of your topic sentences should represent the roadmap of your paper. Therefore, a very quick test to see if you’ve got organization issues is to check your topic sentences: the first sentence of your paragraph tells your reader what the paragraph is about, and every sentence should serve that topic sentence in some way. 

It’s worth thinking about the structure before you start writing. Otherwise, you end up taking more of a random walk than a straight line to your point, and it definitely shows. Think about organization early and often -- your topic sentences can help you with it. 


As with any rule, you can be a little creative here, but checking your topic sentences are a great way to check for structural issues in your writing.


<!-- \ -->

<!-- Bonus 1: You changed tenses mid-paragraph, and/or your methods are written in the present tense. Repeat after me: methods will be written in the past tense. You’re talking about things you did in the past, not things you are doing in the perpetual present. Relentlessly check your prose for the present tense, and also for changes in tense that happen mid-sentence or mid-paragraph. -->

<!-- \ -->
<!-- Bonus 2: You’re not following SI conventions. According to the International System of Units (SI), there must be a space between a value and its unit. 5g should be 5 g, 100ml should be 100 ml, 30ºC should be 30 ºC, etc. Now you know! -->

<!-- *Samuel Beckett: "Ever tried. Ever failed. No Matter. Try again. Fail again. Fail better." -->


\


## Gregory Mankiw: How to Write Well

The following list of writing guidelines is taken from [Gregory Mankiw's](https://scholar.harvard.edu/mankiw/home) [Blog](http://gregmankiw.blogspot.com/2006/10/how-to-write-well.html):

* Stay focused. Remember the take-away points you want the reader to remember. If some material is irrelevant to these points, it should probably be cut.
* Keep sentences short. Short words are better than long words. Monosyllabic words are best.
* The passive voice is avoided by good writers.
* Positive statements are more persuasive than normative statements.
* Use adverbs sparingly.
* Avoid jargon. Any word you don’t read regularly in a newspaper is suspect.
* Never make up your own acronyms.
* Avoid unnecessary words. For instance, in most cases, change
    * "in order to" to "to"
    * "whether or not" to "whether"
    * "is equal to" to "equals"
* Avoid "of course, "clearly," and "obviously." Clearly, if something is obvious, that fact will, of course, be obvious to the reader.
* The word "very" is very often very unnecessary.
* Keep your writing self-contained. Frequent references to things that have come before or will come later, can be distracting.
* Put details and digressions in footnotes. Then delete the footnotes.
* Buy a copy of Strunk and White's (Elements of Style)[https://en.wikipedia.org/wiki/The_Elements_of_Style]. Also, William Zinsser's *On Writing Well*. Read them again and again and again.
    * Zinsser's theory is that: "writing improves in direct ratio to the number of things we can keep out of it."
* Keep it simple. 


<!-- Think of your reader as being your college roommate who majored in English literature. Assume he has never taken an economics course, or if he did, he used the wrong textbook. -->

<!-- * Keep your writing personal. Remind readers how economics affects their lives. -->

<!-- * To mere mortals, a graphic metaphor, a compelling anecdote, or a striking fact is worth a thousand articles in Econometrica. -->



## Rob J Hyndman: Avoid Annoying a Referee


The following list on "How to avoid annoying a referee" is taken from [Rob J Hyndman's Blog](https://robjhyndman.com/hyndsight/how-to-avoid-annoying-a-referee/):


It’s not a good idea to annoy the referees of your paper. They make recommendations to the editor about your work and it is best to keep them happy. 


* Explain what you’ve done clearly, avoiding unnecessary jargon.
* Don’t claim your paper contributes more than it actually does. 
* Ensure all figures have clear (and well sized) captions and labels. 
* Include citations to the referee’s own work. Obviously you don’t know who is going to referee your paper, but you should aim to cite the main work in the area. It places your work in context, and keeps the referees happy if they are the authors.
* Make sure the cited papers say what you think they say. Sight what you cite!
* Include proper citations for all software packages. If you are unsure how to cite an R package, try the command `citation("packagename")`.
* Never plagiarize from other papers -- not even sentence fragments. Use your own words. I’ve refereed a thesis which had slabs taken from my own lecture notes including the typos.
* Don’t plagiarize from your own papers. Either reference your earlier work, or provide a summary in new words.
* Provide enough detail so your work can be replicated. Where possible, provide the data and code. Make sure the code works.
* When responding to referee reports, make sure you answer everything asked of you. (See my earlier post ["Always listen to reviewers"](https://robjhyndman.com/hyndsight/always-listen-to-reviewers/))
* If you’ve revised the paper based on referees’ comments, then thank them in the acknowledgements section.


##  Writing Tips by John H. Cochrane

John H. Cochrane write a now famous paper on **Writing tips for PhD students** which contain many valuable points: 


[**Writing tips for PhD students**](https://static1.squarespace.com/static/5e6033a4ea02d801f37e15bb/t/5eda74919c44fa5f87452697/1591374993570/phd_paper_writing.pdf)


## LaTeX


Use LaTeX for scientific writing - particularly, if some math is involved! The probably easiest way to start with LaTeX is the online editor of [overleaf](https://overleaf.com/). 

* Overleaf allows you to start writing with LaTeX without installing software.
* Overleaf even allows for collaborative writing.


\

Alternatively, you can also install a LaTeX-distribtion on your computer. The following brief instructions on how to set up a LaTeX system on different operating systems is taken from [Rob J Hyndman's Blog](https://robjhyndman.com/hyndsight/latex-setup/):



**MS-Windows:**

* Download and run the setup program for MikTeX. Choose the “basic” system.
* Download and run the installer program for TeXstudio.
* Then run TeXstudio and start typing.



**Mac OS:**

* Download and install MacTeX.
* Then run TeXshop and start typing.



**Ubuntu:**

* Install TexLive and TeXstudio through the software centre.
* Then run Texstudio and start typing.



To make sure everything is working ok, open [sample.tex](https://robjhyndman.com/research/sample.tex) in TeXstudio (or TeXshop or TeXworks) to see an example of a LaTeX file. (You will also need [sample.bib](https://robjhyndman.com/research/sample.bib) stored in the same folder.) Click on "Quick build" (or hit F1) and the file should be processed and appear in a separate window. Study the difference between the original file and the final product to learn some basic LaTeX commands.

For help with learning LaTeX, check out Rob J Hyndman's ["Useful LaTeX links"](https://robjhyndman.com/hyndsight/useful-latex-links/).




## General Paper Structure 

There is not prescribed paper structure in econometrics or statistics, but most papers follow this basic structure which is also recommended for your term/seminar-paper: 

1. **Introduction** (1-3 pages) Here you need to give an easy to read explanation/motivation of the considered method(s), present the existing literature, and finish with a short (one paragraph) outline of the rest of the paper.
2. **1st Main Part: Theory**  Here you need to describe the theoretical properties of the method(s).
3. **2nd Main Part: Monte-Carlo Simulation** Here you need to investigate the properties of the method(s) by means of Monte-Carlo simulations.
4. **3rd Main Part: Real-Data Application(s)** Here you apply the method(s) to real data and interpret the results.
5. **Conclusion** (1-2 pages) This concluding is section gives you the possibility to wrapping up and give an outlook for possible future work.




# How to Present


The following is heavily based on the paper: 

Rob J Hyndman (2011), [Giving a useR! Talk](https://journal.r-project.org/archive/2011-1/RJournal_2011-1_Hyndman.pdf), The R Journal, 3(1), 69--71

\


Giving a talk/presentation is a balancing act in which you have to try to impart some ideas, provide sufficient background and keep the audience interested, all in a very short period of time. I’ve sat through more than my fair share of bad conference talks. Slides full of equations flashing past quickly, tables containing tiny figures that no-one can read, most of the audience lost on the third slide. Anyone who has attended even one conference will have seen such (bad) presentations. 



The problems often stem from confusion about the
purpose of the talk. Some speakers clearly think the
aim of a talk is to impress the audience with their
technical skills, even (or especially) if that means the
audience does not understand what they are talking
about. Others speakers appear to believe that talks
are for those few members of the audience who are
working in the same narrow research area -- and so
no attempt is made to provide an introduction to the
topic. Still others see conference talks as an oral version
of an academic paper, in all its painful detail.




## The Aim of your Talk



* I like to think of talks/presentations as **advertisements for the associated paper**.
* The talk is not intended to cover everything you have done, or even to summarize what you have done. 
* In giving a talk, I am hoping that: 
    * everyone in the audience will have a clear idea of what I have been working on. 
    * some of those in the audience will be motivated to read my paper or put into practice some of my advice.



The tiny tricky details are for the people who read
the paper. Generally, there is no point discussing the
tiny details of proofs, code or algorithm technicalities. Those
who care will explore the details afterwards.


I tend to spend at least half the time going
through a motivating example and reviewing the
relevant background -- most of the audience will
need that context in order to understand what the
talk is about. In fact, it is reasonable to assume that
the audience knows about as much as you did at the
start of your work in this area. That is, probably very
little. So it is important to spend some time providing
background information or you will lose the audience
quickly. Do not assume the audience already knows what you have spent long hours learning on
your own.



## A Suggested Structure


1. Start with a motivating example demonstrating the problem you are trying to solve
2. Explain existing approaches to the problem and their weaknesses
3. Describe your main contributions
4. Show how your ideas solve the problem/example you started with


This structure will not necessarily work for every
talk, but it is a good place to start. In particular, beginning
with a motivating example is much better
than setting up the problem algebraically.


For a 15 minute conference presentation, I divide
the time approximately into 3/4/6/2 minute sections.
Using this structure, you will have barely started
on your own contributions when you are half way
through your allocated time. Resist the temptation to
trim the first two sections. The audience needs time
to absorb the **purpose of your work** and the context
in which it is set.




## Preparing Slides

High quality slides are an important part of a good
presentation. I recommend using the beamer package
with LATEX. 


**Avoid distracting slide transitions** and dazzling
slide themes. You want the audience to focus on your
content, not wonder how you implemented some
gimmick. Save animation for aiding interpretation.


Use at least a **20-point font** so everyone in the
room can read your material. 


**Limit the material on each slide**

* Keep the number of words to a minimum. 
* Do not include every detail of what you plan to say. 
* Keep it simple.
* Resort to text only when illustrations fail you.
* Very often, a table can be replaced with a suitable
graphic.
* If you must present tables, only show the essential
information. No-one is going to read a slide full
of tiny numbers. 
* It is easy, but boring, to have bulleted lists summarizing
your main points. Instead, use pictures and
graphics as much as possible. 
* Give only the most necessary mathematical details.
When you use equations, define your notation.


**Slides are not there to remind you what to say**. 
Use a page of notes for that purpose. The slides are
for the audience -- make sure everything on your
slides is there because it will help the audience understand
what you are saying.



**Slide numbers.**It is useful to add slide numbers so the audience
can refer back to specific slides in question time.


**On your last slide**, give your website or email address
for people to contact you if they want to read
the paper or just ask a
question.



**Refine the slides.** I spend a lot of time going over my slides looking
for ways to improve them. After a presentation is essentially
complete, I go through all the slides to see
what I can remove -- less text is better. I also look for
places where I can simplify the presentation, where
I can replace text with graphics, and where the titles
can be improved. I often spend almost as much time
refining the slides as in creating the first version.



**Always preview your slides** on the computer being
used for the talk. You will look foolish if symbols
and Greek letters that looked OK on your computer
translate into something unreadable on the big
screen. Use pdf-slides!




## Keeping to Time

**Do not deliver a 30-minute talk in 15 minutes.** Nothing
irritates an audience more than a rushed presentation.
It is like trying to get a drink out of a fire hydrant.
Your objective is to engage the audience and
have them understand your message. Do not flood
them with more than they can absorb.


**Cut your material.** Present only as much material as can reasonably
fit into the allocated time. Generally that means no
more than one slide per minute. I tend to use an average
of about 0.8 slides per minute of talking. It is
helpful to use some slides as time-markers and make
sure you are at the relevant slide at the right time.


**Never go over time.** Keep an eye out for signals
from the session chair indicating when you need to
conclude. If necessary, be prepared to cut your talk
short and finish with a quick summary.


**Rehearsing is invaluable.** Practise. Out loud.
Standing up. Using a data projector. Get colleagues
to listen to you, including some who are not knowledgeable
on the topic of your talk; they will be able
to point out places where you may not come across
clearly. After the rehearsal, you may wish to 
**delete some of your material** to ensure the talk can be delivered
within the allocated time.


**Balance the amount of material** you present with
a reasonable pace of presentation. If you feel rushed
when you practise, then you have too much material.




## Giving the Presentation

**Confidence.** By the time you give the talk, you will have spent
enough time preparing your slides and practising
your talk that you should feel confident of giving a
great presentation.


**Talking.** Talk at a pace that everybody in the audience can 
understand. Speak slowly, clearly, and loudly, especially
if your English is accented. Speak
loudly enough to be easily heard by those sitting in
the back row


**Engage the audience.** Speak to them, not to the
projector screen or to your notes. It helps to move
around, look at your audience and smile.


**Do not apologize**

* Never apologize for your slides. Make apologies
unnecessary by producing great slides in the first
place. Do not say, “I know you can’t see this, but
...” If the audience cannot read your slide, there is
no point displaying it.
* Do not apologize for incomplete results either.
Researchers understand that all research is incomplete. 
Just present the results and let the audience
judge. It is okay to say, “work is on-going”.



**When finished**, thank the audience for their attention.
Stay for the entire session, for the courtesy
and benefit of your audience and your co-speakers.
Afterwards, be available for people to ask you questions.



\


## Final Advice {-}

My final advise for our last two chapters on writing and presenting:

> Everything should be made as simple as possible, but not simpler.

(Quote by Albert Einstein, [or some other smart person](https://quoteinvestigator.com/2011/05/13/einstein-simple/))