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.

Andrew Kuchling

March 27, 2009
Tweet

More Decks by Andrew Kuchling

Other Decks in How-to & DIY

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. Have a minimal amount of text on each slide. brief

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

    key - if slides are underlining your exact wording, you need to get words right
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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>
  16. 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>
  17. - 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>
  18. 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
  19. 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>
  20. 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
  21. 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
  22. 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>
  23. 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
  24. 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>
  25. 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)
  26. 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
  27. www.peterursbender.com/spp/ "Secrets of Power Presentations", Peter Urs Bender online book:

    - covers the basics - organizing your presentation - body language
  28. "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.
  29. prepare your computer - turn off IM, screensaver, Twitter app

    - tidy your desktop; remove clutter, embarrassing things - <change>
  30. 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
  31. "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)
  32. - 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,