2010/Give a Great Tech Talk

From Open Source Bridge Wiki
Jump to: navigation, search

Why do so many technical presentations suck? Make sure that yours
doesn’t. Josh Berkus and Ian Dees will show you how to share your
ideas with your audience by speaking effectively and (when the
situation warrants it) showing your code.

Speakers: Josh Berkus, Ian Dees

Return to this session's details

(Add your notes here!)

Topics Covered

  1. How to prepare for a talk
  2. Nobody cares about your slides
  3. … but make good ones anyway
  4. Seven Habits of Ineffective Speakers
  5. Audience Interaction 101
  6. When the demo crashes
  7. Curating code examples
  8. Audience outside the lecture hall
  9. Q&A


Questions for Ian & Josh

  • One audience member mentioned that it can be helpful to choose syntax-highlighting colors that match the culture / standard documentation of the code you're presenting.
  • Callie Carroll points out that having both audio and visual versions of a talk is actually a good thing, for accessibility reasons.
  • Q: How can a presenter keep his talk fresh if he has to give it over and over and over again? A: As you customize the talk for each individual audience, take the opportunity to make a few small changes to your slides.
  • Q: How do I convince my co-presenter to rehearse? A: Tell them it's for your own benefit: "It would really help me get the timings down if we could run through this together; do you mind?"

Contributed notes

(these are unedited, apologies - Jason L)

Your Topic:

  • know it well, enthusiastic about, time slot consideration
  • use a timer (some remotes have timers right on them that can buzz you)

Know Your Audience:

  • generic will suck;
  • professions, cultures, etc (are they question askers?)
  • why are they at the conf, what is their interest, what do they know already, what style/format, any common things

Talk Prep

  1. notes
  2. story
  3. write script
  4. timings
  5. create slides (notice that this is all the way at #5!)
  6. rehearse - record and watch for chronic bad gestures/speech
  7. revise
  8. re-rehearse

basic stories (short story type of talk - one thing happens)

  1. from ignorance to knowledge
  2. quest/solving a problem
  3. top to bottom, bottom to top
  4. theme & vars
  5. catalog

Alternatives to slides: whiteboard, video, demos, audience exer

Good slides:

  • one idea, one slide
  • stand still: want attn on slide; move around: draws attn to you
  • themes: simple, stock template - use master slides feature of presentation sw
  • light on dark or dark on light? dark on light might be better (especially for code)
  • yellow or white on color; color on yellow/white

7 bad habits

  1. chained to chair/podium
  2. about me/about us (keep it brief or not at all)
  3. read every line of every slide (slides should be a backdrop)
  4. Dr Bronner's theme: use every space available, crowded together, text or graphs, any architecture diagram (break things up; make a story!)
  5. bait n switch: not all stuff that was in description is covered; promise working code or demo and then just show slides; described expert/in-depth/hacking/etc and gave a beginner level talk/intro, and vice versa; in-depth and then give brochureware/marketing; grabbag - include random shit
  6. Time is an illusion - don't worry about it! (yes, worry about it)
  7. Panic: apologize; fiddle with stuff in real time; end session early

Audience Interaction

  • Eye contact, body language (open)
  • ask for a response: engage, wake them up; ask who they are and collect that information mentally (like what experience they have); don't get stuck with the bad professor questioning (waiting for the correct answer BS). Know if it's an audience that will be hesitant - might be worth planting someone to open it up.
  • Beta-test jokes - with people different than you and close to audience
  • Let audience know when you'll be taking questions
  • don't answer a ? you don't know the answer to with BS
  • Don't give all your time to a frequent questioner
  • Aud Participation - choose the right people. don't do open-ended. have a backup plan.

Code Examples

  • use html export to get syntax highlighting
  • github: undees snippetize
  • have a video/screencast for backup of failing demo
  • use keynote, oo impress, powerpoint
  • github: showoff (for bash fakeouts and good code presentation)
  • give links to more code

Avoiding Demo Failure

  1. don't be ambitious/risky
  2. test hardware
  3. drill demo repeatedly
  4. rewindable VMs (for things that might break after it;'s run once)
  5. fake demo: screens, video, etc - ttyrec records shell session
  6. alternate/extra demo
  7. never cascade demos (don't make them depend on each other)

Remember the audience outside! speaker notes for slides is good for non-live readers; audio or notes, don't need both. Share on slideshare, etc.