Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Giving Python Talks

Giving Python Talks

This session will discuss how you -- yes, *you* -- can give talks about Python at your local user group and at events such as PyCon. The talk will discuss how to decide upon a topic, how to prepare the presentation, and suggest various tips for improving your delivery.

Delivered at PyCon 2009.

E2cb0083d4d61cebb1325281f88f3843?s=128

Andrew Kuchling

March 27, 2009
Tweet

Transcript

  1. How to Give a Python Talk Andrew M. Kuchling PyCon

    2009 - Good morning. - Welcome to 'how to give a python talk' - many resources on giving talks - will discuss: - why you should - selecting a topic - preparing for talk - coping w/ stagefright
  2. Muphry's law If you write anything criticizing editing or proofreading,

    there will be a fault in what you have written. Text www.flickr.com/photos/encarna/262751140/ - rule of Internet corrections - will always make mistake when criticizing another's error - am not a professional speaker/trainer - don't claim to be outstanding speaker - been to many talks - wanted to make suggestions for future speakers
  3. flickr.com/photos/liz_noise/1934616507 - public speaking scares people - surveys show it's

    top social fear - why? everyone looks at you, poss. judging you - what if you mess up? on your permanent record? - why go to the trouble? - like programming, speaking is a useful skill - personal, work, political life - lessons w/ physical audience also apply to podcasts, videos
  4. Possible venues • Department or company seminars. • Your local

    Python user group. • Non-Python user groups • PyCon, EuroPython, PyCon UK, OSCON, others • BarCamps flickr.com/photos/hitachi_data_systems/210136810/ - PyCon is a once-per-year event, but there are lots of other places you could give a talk. - can start small, w/ present. to co-workers or department - audience is mostly acquaintances - local Python user group - hard to find a speaker every month; they'll be glad to hear from you - don't have one; start one! title-search for "usergroup' in Python wiki - don't forget other user groups: Linux, Oracle, web devel. - larger conferences: larger, unfamiliar audiences; a tougher starting point. - often have open space where you can grab a block of time - less-structured conferences: Foo Camp, BarCamp, etc. - often more interactive: 10min of overview, followed by discussion - different venues have different requirements - user group: single speaker, about an hour, flexible on time - conference: shorter 15-45 minute blocks; no flexibility on time - different formats suited to each venue
  5. Lightning Talks Title Code Screenshot URL 3-4 common formats for

    tech talks Lightning talks: - 4-5min, 3-4 slides - good starting point; short, easy to rehearse several times - audiences love them: 18 ideas in 90 minutes - strongly suggest attending LT session later today
  6. Standard Presentations Slide 1 Title Slide 3 Slide 2 Slide

    4 Text Text Text Code what we think of as presentations - 1-2min/slide - 30-60 slides per talk - slides are fairly dense w/ bullet-point text, graphics - Can be well-done, can be boring
  7. Lessig-style Example: search for "lessig ted talk" Lessig-style - named

    after Lawrence Lessig of EFF/Commons - not unique to him, but gave widely-seen-online exemplar - "lessig ted talk" - many slides, possibly 100s, w/ minimal content on each - instead of text, a slide might show <change>
  8. flickr.com/photos/ smithsonian/3302801677 a suitable photo that illuminates a point

  9. Have a minimal amount of text on each slide. brief

    text expressing a principle or statement
  10. simple even a single relevant word Preparation & practice are

    key - if slides are underlining your exact wording, you need to get words right
  11. Selecting a topic • Introduce a project you've written. •

    Introduction to libraries/ modules you use a lot. • Explore a language feature. • Discuss your past experience flickr.com/photos/eklektikos/2541408630/ what can you talk about? - some venues care about novelty - not so critical for tech events - all material is new to someone - introduce project you've built - discuss a library or app you use personally
  12. Ideas from past PyCons •Go to the Python wiki: wiki.python.org/moin/

    •Do a title search for 'Feedback' One source of info: PyCon attendee surveys - favorite talks - topics they'd like to see - go to Python wiki; title-search for Feedback
  13. 2005 "PyWebOff: Mapping the Python Web Application Frameworks", Michelle Levesque

    "Iterators and Generators", Alex Martelli "Design Patterns and Python OOP: Objects by Design", Alex Martelli "Keep it Simple with PythonCard", Kevin Altis "Object-Oriented Design with Python", Bruce Eckel "matplotlib - from Brain Surgery to Rocket Science", John Hunter & Perry Greenfield top talk is a comparison of then-available web frameworks - useful to listeners who face same decision - OK if you're not expert on any projects; neither is listener - may get pushback from projects, if you miss a special trick or approach 3 are language talks: - might think there's nothing to be said about basic Python features - aim at intermediate users (know syntax, wonder how to design & structure) - intermediate users are under-served - (not to say you should avoid beginner or advanced talks) - easy to explain syntax; hard to talk about less clear-cut issues
  14. 2006 "IronPython implementation", Jim Hugunin "Python in Your Pocket: Python

    for Series 60", Matt Croydon "Using Django to supercharge Web development", Adrian Holovaty "The State of Dabo", Ed Leafe "Python Can Survive In The Enterprise", Mike Pirnat & David Stanek "PyPy: Where we are now", Michael Hudson & Christian Tismer "History of Python", Guido van Rossum "Effective AJAX with TurboGears", Kevin Dangoor "Creating Presentations With Docutils and S5", David Goodger 4 are surveys or state-of-project talks - not everyone follows development - users like knowing what's been done, what's coming - appeal to current users, & potential users
  15. 2007 "twill, scotch, and figleaf: Tools for Testing", C. Titus

    Brown "SQLAlchemy: The Front-to-Back Database Toolkit" Mark Ramm-Christensen "Interactive Parallel and Distributed Computing with IPython", Brian E Granger & Fernando Perez "IPython: Getting the Most out of Working Interactively in Python", Fernando Perez & Brian E Granger Web Frameworks Panel "IronPython: Present and Future", Jim Hugunin "Using Stackless", Andrew Dalke we began introducing panel discussions - provide guidance like a comparison talk - burden is spread across several people, not one - often more interactive for audience
  16. 2008 "Core Python Containers -- Under the Hood", Raymond D

    Hettinger "The State of Django", Adrian Holovaty "Sights and Sounds with pyglet", Alex Holkner "Using PyGame & PySight to Create an Interactive Halloween Activity" John Harrison "The State of PyPy", Laura A Creighton & Maciej Fijalkowski "SQLAlchemy 0.4 and Beyond", Mike Bayer "IronPython: The Road Ahead", Jim Hugunin "nose: testing for the lazy coder", Jason Pellerin recaps earlier comments - top talk: basic-lang on containers - four state-of-project talks - 2 PyGame talks - they make for lively demos, entertaining talks try to be entertaining - doesn't mean telling jokes - means being enthusiastic - active; speaking clearly; appealing to audience to be appealing,<change>
  17. Think about your audience flickr.com/photos/jakecaptive/3205277810/ you must think about audience.

    - beginner/intermediate/advanced? - stay consistently focused on that level - why are they interested? - what do they want to accomplish? - set a goal; motivate the audience to do something - use a new package - program or perform tasks differently, in new better way - provide realistic amount of material <change>
  18. - too short > too long - leave audience wanting

    more - too fast > too slow - too fast may lose some people, but - too slow is boring; no one pays attention - for short talks, give basic overview & principles - + a few specific cases - + where to get more info - LTs push this to extreme - title; one example; second example; URL for more. - Give info that's useful & definite - example due to Mark-Jason Dominus - we've all seen talks like this <change>
  19. XML Stands for: •eXtensible •Markup •Language XML: - stands for...

    - expand on each word for 30 seconds
  20. What XML is Used For • XHTML: stricter version of

    HTML. • DocBook: for writing books and articles • SVG: Scalable Vector Graphics • OASIS OpenDocument Name-drop a bunch of particular uses: - XHTML - DocBook
  21. XML Standardization • Predecessor: SGML from the 1980s • HTML

    is an application of SGML • XML tightens the rules, is easier to implement. • 1996: W3C working group started • 1998: W3C Recommendation published Discuss the history of XML What do these intros do? Basically, eat up time <change>
  22. flickr.com/photos/jpockele/291728595/ XML is a big topic - cannot give much

    info in a short talk - often reduced to vague generalities - will not help people do stuff. - if you spend 5 minutes on this, 5 min of 1/2hour block is 20% of talking time! - Give minimum details to understand the talk - Jump into code, instead. - here's the XML slide from my ElementTree talk
  23. Anatomy of an XML Document <document> <?xml-stylesheet type="text/css" href="basic.css" ?>

    <!-- Generated with ElementTree --> <author name='amk' href="http://www.amk.ca" /> <p class="note">Note.</p> <p class="warning">Warning paragraph.</p> <p>Regular paragraph.</p> </document> - here's complete example XML document - looks like HTML; has stricter rules - for example: every element must have start/end tags - attribute values must be quoted - docs can also contain comments - PIs: instrs. to application using XML - next slide was a code example - let's now talk about preparing for a talk
  24. Slide design • Keep it simple • Slides are for

    audience • Use software you're comfy with • A talk is a performance! flickr.com/photos/ onemananhisdog/3263345266/ a big part is slide design; tech talks usually need to show code, diagrams Keep slides simple - don't cram too much onto each one - don't use hard-to-read colour scheme - black-on-white always works - photos, related or not, break up monotony & add interest Slides are for audience, not you: - don't read them verbatim - don't rely on them to remember what to say -- use index cards, speaker notes Lots of choices for making slides: - Powerpoint/Keynote/OpenOffice are the big ones - CSS stylesheets for writing presentations as HTML - PDF viewers often have full-screen mode; use anything that outputs PDF - once saw a talk written in LaTeX, presented using xdvi; worked fine - use what's comfortable for you (more) Largest point: - talks are performance problems, not design problems - don't spend endless hours tweaking - (good talk, plain slides) > (bad talk, fancy slides) most critical tip for good talk: <change>
  25. Rehearse your talk let me say that again: <change>

  26. Rehearse! - don't try to wing it, or improvise -

    only brilliant can pull it off - presenting w/o practice is disrespectful to audience - says it's not worth your time to ensure their time is spent well
  27. Practice several times: 1. Polish the outline (don't worry about

    time) 2. time how long it takes 3. fix phrasing in memory 4. deliver presentation to someone else flickr.com/photos/lrargerich/2827391707/ don't practice just once or twice, at last minute - first time: figure out what to say; - get your outline & content straightened out - second time: time how long it takes. Edit/restructure accordingly - further times: fix phrasing in memory - give talk to someone else (co-workers, user group). - stuffed animals as a last resort - it really is different w/ someone looking at you Preparing on day of talk: <change>
  28. flickr.com/photos/28405532@N02/2814951286/ everyone has it to some degree practicing will help

    you feel in control breathe deeply before you start Remember: - audience is on your side - they cared enough to attend - want to hear what you have to say Keep audience on your side by not annoying them: - use the mike! - repeat questions from audience - questioners will be speaking in your direction, not theirs - don't fidget (pacing too much, toying with an object) - if you can't help fidgeting, don't make noise (jingling change, tapping a pen)
  29. flickr.com/photos/nate_kate/2968445502 Where can you learn more? - there are lots

    of books - few focus on tech presentations - most are about generic business talks, w/ sales undercurrent - read one; maybe skim one or two more
  30. www.peterursbender.com/spp/ "Secrets of Power Presentations", Peter Urs Bender online book:

    - covers the basics - organizing your presentation - body language
  31. "Public Speaking for Wimps: Staying Cool When Stage Fright Strikes",

    Rich Mintzer & Peter Murdock another slim one (128 pages) concentrates on the stage fright and acting aspects how to use gestures & body language how to practice effectively discusses various relaxation techniques - Actor Laurence Olivier once wrote - "Stage fright is always waiting outside the door, any door, waiting to get you. You either battle or walk away." - The battle is not hard as you think, and it's worth the effort. - I look forward to seeing what all of you can do.
  32. None
  33. prepare your computer - turn off IM, screensaver, Twitter app

    - tidy your desktop; remove clutter, embarrassing things - <change>
  34. http://www.urgle.com/~mike/optical/Illusion.html this avoids distracting audience during demos - change your

    background to not be distracting too <change>
  35. flickr.com/photos/pagedooley/2682945225/ something peaceful. Show up early to test w/ equipment

    Bring presentation on flash drive in case your laptop dies/isn't compatible
  36. "How to Craft Successful Business Presentations", Patrick Forsyth another one

    that covers the basics written by a UK consultant while I was reading, I heard Steve Holden's voice in my head 192 pages (my taste is for books that are slim and focused instead of enormous volumes)
  37. - Laurence Olivier, in his 1948 Hamlet - in 1970s,

    when he was mid-60s, struck by stage fright - Wrote "Stage fright is like the character in 'The Turn of the Screw' who never appears; he is always waiting outside the door, any door, waiting to get you. You either battle or walk away." - The battle is worth it,