Armando's Paper Writing and Presentations Page

Hints for Giving a Good SURF, REU, etc. Talk


  1. Know thy audience and watch thy jargon
  2. Keep the big picture in mind
  3. Tell me a story, don't read me an article
  4. Pace yourself
  5. What did you just say again?
  6. There will be questions...

Know thy audience and watch thy jargon

Know your audience!  At typical REU/SURF presentations, the audience consists of a wide variety of people from different disciplines.  Roughly, the structure of your talk should reflect the following goals: (a) hook everyone (including those not in your area) on your topic/problem; (b) impress the experts with your specific work; (c) wrap up and recapture the attention of the non-experts.  The fraction of your talk devoted to each of these depends on the level of sophistication of your audience.

Framing the problem can be a challenge.  Are there popular-press or "real-world" examples you can appeal to in order to illustrate what you're doing?  Even examples from Star Trek can be useful, since a lot of technology areas are rapidly approaching the abilities envisioned in that venerable show.  Graphics, photos, and short video clips are also useful.  Your project advisor can probably help you find something appropriate.

Beware of jargon, which covers both terms and concepts.  Some people don't know what public-key cryptography is; others are specialists and just want to know which cryptosystem you used.  Some people aren't familiar with the concept of separating a user interface from a device or application; plan to explain it if needed.

Keep the big picture in mind

What is the high level view of what's going on?  You need to motivate the overall project to an audience who might be thoroughly unfamiliar with it.  In a SURF talk, it might take up to 1/3 of the talk to motivate the problem and be sure everyone understands (at least at a high level) why it's useful, interesting, etc.  This is time well spent: if people don't understand the ultimate goal, they probably won't pay attention to what you did.

How is the big picture divided into subproblems, and where do you fit in?  Now that the big picture is clear, what are the specific subproblem challenges?  Which part of which subproblem are you working on?  Some of this will necessarily get into details that not everyone in the audience can follow.

If your efforts succeed, what will you have demonstrated?  Another way to ask this is: what is the "research question" (or questions) being addressed here?  In other words, ten years from now, when the hardware, software, etc. have all changed and the computers of the day make today's computers look like Tinkertoys, what fundamental nugget of an idea will still be considered relevant and applicable?  This is often very hard to identify, and it may be that your own piece of the project contributes only a small part toward forming that Big Idea, but research is a building that has to be built one painful brick at a time.  (Ask any Ph.D. student.)

Tell me a story, don't read me an article

Rehearse your talk enough that you don't need paper notes (or, at most, minimal notes - two or three 3x5 index cards for the whole talk).  If you make eye contact, engage your audience, and tell them a story, they will pay attention.  Try not to read from notes; they can read a paper as well as anyone.  Having a speaker bring the material to life is what makes a talk different and potentially a better avenue for communicating your work to a lay audience.

Don't be afraid to use humor.  If a funny picture, animation, joke, etc. is appropriate, it keeps the audience interested.  But don't fall into the extremely annoying trap of using these gratuitously; it distracts the audience and gives the impression that you are using these to cover a lack of competence with the material.

Pace yourself

You won't have time to say everything you want.  The higher level the talk, the less detail you'll have time for.  A time-tested rule of thumb is: 2 minutes per slide.  This sounds conservative, but it is very well borne out on average.  Therefore, exlcuding the title/outline and conclusion slides, you should have half as many slides as you have minutes to speak.

Find a couple of key "timepoints" in the talk ("By the time I get to this slide, I should be n minutes into the talk").  Once again, rehearsal is key to debugging this.  Remember, if you run out of material early, you are still prepared with a level of detail deeper than your talk, so you can use the extra time to elaborate on a particular point of interest to you; but if you are running short of time, you won't be able to communicate everything you want to say, and your audience will not come away with a representative picture of what you did or why they should care.

What did you just say again?

Especially if the middle part of your talk is aimed at technical experts, be sure you recap towards the end what the overall problem was and what your contribution was.  Plan on 1-2 slides for this.  People best remember the beginning and the end, so make sure these are rock solid.  (Ask anyone who has written a Broadway musical if you don't believe this.)  It may be appropriate to include "future work" here - things left to be done (some of which may have been discovered as a result of your work, which is always good) and new issues that came up as a result of your work.

There will be questions...

People will ask about stuff not in your talk.  The main preparation/rehearsal, then, is to know your material at one level of detail deeper than your slides.  Usually you cannot predict the questions; so, although you should make sure you can explain every point on your slides in additional detail if necessary,  do not expect that those are the only questions you will get.  People remember how well you handled your questions, since it demonstrates real familiarity with your material (anyone can rehearse and deliver a prepared talk on a topic they know little about).

Helpful Hints for Technical Paper Writing

Acknowledgments: Particularly influenced by Seth Hutchinson (MS thesis advisor), Eric Brewer (PhD thesis advisor), John Mullin (high school English--really!), and benefited from proofreadings by too many people to mention by name.

Note: This is a page about writing technical papers, but many of the techniques also seem applicable to both non-technical writing and giving presentations.

Vision, Implementation, and Survey Papers

In a vision paper, you describe your grand scheme of the world and why it is good. You need some data to back up your statements, but this is not a detailed measurements paper. The goal of this paper is to convince the reader that your scheme is interesting, different, better than other schemes that have addressed similar problems, raises legitimate research questions, and is therefore worth spending the time to pursue research on.

The implementation paper, by contrast, gives detailed measurements of a system that was perhaps described in a previous vision paper. The goal here is to demonstrate what you learned from actually building the system: Did it validate your research hypothesis? What came out differently than you expected, and why? How much better, quantitatively, is your design than others'?

Survey papers: TBD...

Before You Write...

Starting Checks

The Actual Paper: Writing

  1. start from the outline.
  2. Make the outline reflect the level of subsections: for each subsection, write no more than two lines describing the purpose/goal of that subsection. This text will NOT be part of the paper - it is only there to remind you what you are trying to accomplish. It is ESSENTIAL that you be able to capture the purpose of a subsection in one or two lines. If you cannot do this, then you probably don't understand what the subsection is really about, and when you try to write the text, it will be jumbled.
  3. Then, for each subsection, map out specific paragraphs: for each paragraph, write one sentence that explains the topic or main goal of just that paragraph. Again, this sentence probably will NOT make it into the actual text. It's important to keep it to one sentence. (As every style manual will tell you, including Strunk & White, virtually every well-formed paragraph does indeed have one sentence that explains the point of the paragraph, with the other sentences supporting or expanding on the point of the topic sentence.)  If you cannot fit the point of the pargraph into 1 sentence, the paragraph is probably making >1 point, so should be split into multiple paragraphs.
  4. Read through everything you have written and see if it has a logical flow, ie if you believe it represents your work adequately.
  5. Give what you have written to a technical colleague completely unfamiliar with your work (but able to understand the computer science part), have them read it, then have them tell you (without looking at it) what s/he thinks the main point and contributions are.
  6. If all goes well, now replace the topic sentences with complete paragraphs.

    This way of writing will not yield a shakespearean work of literature, but it is consistent and will result in readable, logically organized prose by construction.


The Actual Paper: Revising/Editing

About Writing

It's often said, correctly I think, that most technical people don't write well. This doesn't mean that they lack knowledge of grammar or spelling (though this is sometimes the case), but that they don't know how to organize their writing at the level of paragraphs.

Final Checks

Remember that this will be read by people who (a) have never heard of you and the review is anonymous anyway, (b) have never heard of your project, (c) are reading about 15-20 papers apiece, all in different subject areas. They will spend the first 5 minutes deciding if your paper is actually good enough to be worth a fully detailed read; they will then spedn an hour or so reading it in detail, trying to figure out (a) what your contribution is, (b) if the contribution is substantial enough to be worth publishing, (c) if the contribution is "feasible" (ie it is implementable and therefore would be useful to someone).

John Ousterhout's Hints for Reviewing Papers

I preface these with some high-level questions of my own that I try to answer quickly on a first pass. Note that the answer to each question tells you something about the technical content of the paper, whereas the ease of extracting the answer to each question tells you something about the quality of the writing. For example, a paper may have a really great main contribution that is so poorly expressed that it takes you a couple of passes just to figure out what the paper is "really" about.

John Ousterhout delivered the following wisdom to his UC Berkeley CS 262 (advanced topics in operating systems) class in Fall 93, as the ISCA deadline approached.


Goals of Review


Short rules to triple-check your paper