Comments on: PyCon Talks http://blog.ianbicking.org/2008/03/21/pycon-talks/ Wed, 08 Sep 2010 10:58:09 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Cory Bloyd http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16735 Cory Bloyd Tue, 15 Apr 2008 04:06:11 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16735 AFAIK, there are two primary values in conferences: 1) Networking 2) Presentations that quickly help you decide what to invest more time researching (and what to skip!) You can't hope to teach in short talk. Instead help the audience understand that the topic really is/really is not valuable to them and tell them where to go for more info if they want it. If that is "all" you managed to do then Bravo! AFAIK, there are two primary values in conferences: 1) Networking 2) Presentations that quickly help you decide what to invest more time researching (and what to skip!)

You can’t hope to teach in short talk. Instead help the audience understand that the topic really is/really is not valuable to them and tell them where to go for more info if they want it. If that is “all” you managed to do then Bravo!

]]> By: Kumar McMillan http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16244 Kumar McMillan Wed, 26 Mar 2008 19:24:22 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16244 I too was wondering what might make a better talk format for PyCon next year. The only conclusion I've come to is that 4 tracks are *way* too many -- even last year's 3 tracks seemed easier to handle. Also, I agree that open spaces and/or sprints seem the most useful, although I didn't have enough time to make the most of them this year. As for talks that teach you or introduce you to a tool, I find that often I *want* to read the documentation for a tool but for whatever reason never get around to it. For example, I've always been curious about <a href="http://www.pyglet.org/" rel="nofollow">pyglet</a> and Richard Jones' talk on it this year was amazing. It didn't fully explain how to use it of course but gave enough "cool stuff" to get me interested and also enough technical details to answer the question "why pyglet?" (like, how all the bindings are mainly done with native OS components for efficiency). I probably could have gotten this all from reading the docs and viewing demos but I feel my experience justified the talk. I too was wondering what might make a better talk format for PyCon next year. The only conclusion I’ve come to is that 4 tracks are way too many — even last year’s 3 tracks seemed easier to handle. Also, I agree that open spaces and/or sprints seem the most useful, although I didn’t have enough time to make the most of them this year. As for talks that teach you or introduce you to a tool, I find that often I want to read the documentation for a tool but for whatever reason never get around to it. For example, I’ve always been curious about pyglet and Richard Jones’ talk on it this year was amazing. It didn’t fully explain how to use it of course but gave enough “cool stuff” to get me interested and also enough technical details to answer the question “why pyglet?” (like, how all the bindings are mainly done with native OS components for efficiency). I probably could have gotten this all from reading the docs and viewing demos but I feel my experience justified the talk.

]]> By: ScW http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16206 ScW Mon, 24 Mar 2008 14:34:28 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16206 Ian, again, I had the same issue... how much to focus on code versus the motivation and overview. I believe the same complaint about the code might have been directed at my presentation. I didn't hit code until around the 10 minutes to go mark either. And really, it was for a similar reason, I wasn't going to have time to teach something... I was encouraging the use of something (the django admin interface in my case) for a variety of different problems. What code I did show was to give a flavor for how little was required to get up and going... just to back up my earlier points rather than to teach... and I referred them to my big honking paper which essentially spoon fed them the "how". As for your talk, I enjoyed it. I got what I needed out of it. I knew I wasn't going to learn all the nuts and bolts but that I would get pointed in the right direction with plenty of backup as to why to go in that direction and why it was okay to bother with it all. Very practical and useful to me. If someone was expecting to be taught all the ABC's for doing something from beginning to end... they must grossly underestimate the complexity of everything in life. Ian, again, I had the same issue… how much to focus on code versus the motivation and overview. I believe the same complaint about the code might have been directed at my presentation. I didn’t hit code until around the 10 minutes to go mark either. And really, it was for a similar reason, I wasn’t going to have time to teach something… I was encouraging the use of something (the django admin interface in my case) for a variety of different problems. What code I did show was to give a flavor for how little was required to get up and going… just to back up my earlier points rather than to teach… and I referred them to my big honking paper which essentially spoon fed them the “how”.

As for your talk, I enjoyed it. I got what I needed out of it. I knew I wasn’t going to learn all the nuts and bolts but that I would get pointed in the right direction with plenty of backup as to why to go in that direction and why it was okay to bother with it all. Very practical and useful to me. If someone was expecting to be taught all the ABC’s for doing something from beginning to end… they must grossly underestimate the complexity of everything in life.

]]> By: Michael Foord http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16184 Michael Foord Sun, 23 Mar 2008 22:01:38 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16184 I agree that 30 minutes is too short to actually teach anything - it is about right to give an overview but little more (I enjoyed your talk by the way). Most of the other conferences I go to schedule talks for an hour. I think mixing it up a bit for talks at PyCon would help. I thought the lightning talks on Saturday were ok - even some of the sponsor ones. ;-) I agree that 30 minutes is too short to actually teach anything – it is about right to give an overview but little more (I enjoyed your talk by the way).

Most of the other conferences I go to schedule talks for an hour. I think mixing it up a bit for talks at PyCon would help.

I thought the lightning talks on Saturday were ok – even some of the sponsor ones. ;-)

]]> By: Ian Bicking http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16155 Ian Bicking Sat, 22 Mar 2008 17:48:24 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16155 Lots of people have mentioned the heckler. While it caught me a bit off guard, I actually was happy to get a little push-back -- made the talk seem a little more exciting ;) Lots of people have mentioned the heckler. While it caught me a bit off guard, I actually was happy to get a little push-back — made the talk seem a little more exciting ;)

]]> By: Marius Gedminas http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16147 Marius Gedminas Sat, 22 Mar 2008 15:08:36 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16147 "If you want to learn to use a tool you should read the documentation, sit down with a computer, and give it a try. You certainly shouldn’t come to a talk." Spot on! However, when you don't know which tool to pick and study for a particular task, a talk could give you an idea. “If you want to learn to use a tool you should read the documentation, sit down with a computer, and give it a try. You certainly shouldn’t come to a talk.”

Spot on! However, when you don’t know which tool to pick and study for a particular task, a talk could give you an idea.

]]> By: Ned Batchelder http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16135 Ned Batchelder Sat, 22 Mar 2008 11:54:59 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16135 Ian, you make an interesting point about talks that motivate interest vs. talks that dive deep technically. I think one of the points of friction that causes discontent with Pycon talks is that the talk abstracts often sound like the second kind even though the content ends up being the first. For example, the abstract for your talk is a little ambiguous, and there are plenty of people at Pycon who already know they want to consume HTML. On the other hand, there were other talks that immediately jumped to technical details without giving me any sense of why I should care. Looking over the pycon speakers' tips: http://us.pycon.org/2008/conference/helpforspeakers/ , there's very little guidance on these points. BTW Ian, good job handling the heckler during your talk. It came up again in the comments on my Pycon notes blog post! Ian, you make an interesting point about talks that motivate interest vs. talks that dive deep technically. I think one of the points of friction that causes discontent with Pycon talks is that the talk abstracts often sound like the second kind even though the content ends up being the first. For example, the abstract for your talk is a little ambiguous, and there are plenty of people at Pycon who already know they want to consume HTML.

On the other hand, there were other talks that immediately jumped to technical details without giving me any sense of why I should care.

Looking over the pycon speakers’ tips: http://us.pycon.org/2008/conference/helpforspeakers/ , there’s very little guidance on these points.

BTW Ian, good job handling the heckler during your talk. It came up again in the comments on my Pycon notes blog post!

]]> By: Feihong Hsu http://blog.ianbicking.org/2008/03/21/pycon-talks/comment-page-1/#comment-16126 Feihong Hsu Sat, 22 Mar 2008 03:52:32 +0000 http://blog.ianbicking.org/2008/03/21/pycon-talks/#comment-16126 I did a 30-minute talk about the Python.NET module. Since Python.NET is not a well-known module, I focused more on why people might want to use it, rather than how to use it. I think this is a good strategy: Use the talk to give the introduction and motivation for your topic, including some small demos/examples, and of course allow for a few questions. Then schedule an Open Space sometime after the talk for the people who want more technical details. However, I think this strategy works well only if you schedule the Open Space before the start of the conference. I scheduled it about a week beforehand to make sure that I could get a decent room. Also, I was able to use this time to contact presenters who were talking about related subjects, so that we could do the Open Space together (Q&A works better when there's more than one expert in the room). The other presenters and I created a wiki page for our Open Space and wrote out a list of possible things to discuss. We promoted the Open Space on our respective mailing lists. I wanted to make sure that people who attended my talk were aware of the Open Space, so my third slide contained the full details for it. Because of our preparation, we had a fairly productive Open Space. My only regret is that I didn't reserve a projector. With the number of people who showed up, we could easily have gone through a short round of lightning talks. I did a 30-minute talk about the Python.NET module. Since Python.NET is not a well-known module, I focused more on why people might want to use it, rather than how to use it. I think this is a good strategy: Use the talk to give the introduction and motivation for your topic, including some small demos/examples, and of course allow for a few questions. Then schedule an Open Space sometime after the talk for the people who want more technical details.

However, I think this strategy works well only if you schedule the Open Space before the start of the conference. I scheduled it about a week beforehand to make sure that I could get a decent room. Also, I was able to use this time to contact presenters who were talking about related subjects, so that we could do the Open Space together (Q&A works better when there’s more than one expert in the room). The other presenters and I created a wiki page for our Open Space and wrote out a list of possible things to discuss. We promoted the Open Space on our respective mailing lists. I wanted to make sure that people who attended my talk were aware of the Open Space, so my third slide contained the full details for it.

Because of our preparation, we had a fairly productive Open Space. My only regret is that I didn’t reserve a projector. With the number of people who showed up, we could easily have gone through a short round of lightning talks.

]]>