Great Technical Talks(blog.testdouble.com)
blog.testdouble.com
Great Technical Talks
http://blog.testdouble.com/posts/2013-08-29-great-technical-talks.html
8 comments
I'm organizing the JavaScript track for Codemash 2014, a large generalist track in Ohio. This post represents my thoughts on what holds back most technical talks and what sets apart great ones.
While content is there, it reads like marketing text.
> Near-term trends and innovations that people can grapple with or adopt today in hopes of being well-positioned tomorrow > Medium-term rumblings... > Long-term visions of the future that contextualize today's fashions within the broader strokes...
As someone who is presenting at his first national conference soon, I was hoping to read through this article and get some good insight. Your list of 4 items amounts to advice that can be summed up as:
1. Old lessons applied to new technology. 2. Future-proofing your skill-set. 3. Analyze today's hard problems and share new solutions. 4. Bold, new ideas that we otherwise wouldn't make the time for.
And this can be summed up in 3 steps:
1. Present a problem. 2. Present solutions to the problem. 3. Solve the problem with the solutions.
Or, more concisely:
1. Solve a problem.
Whether the problem is an old or new problem is irrelevant. And whether the solution is old or new is irrelevant. This is essentially covered in the Angular example.
The result of solving a problem is having to describe the problem. And usually that's best done with a story.
1. Tell a story about solving a problem.
This provides context. And, everyone loves a good war story. This helps you connect (as mentioned in the connect portion of the article). Also, by telling a story, and solving a specific or specific problems, you avoid that general overview. You have to dig into specifics, because your problem was specific.
So, the shortest advice I can sum up is: Tell a problem solving story.
> Near-term trends and innovations that people can grapple with or adopt today in hopes of being well-positioned tomorrow > Medium-term rumblings... > Long-term visions of the future that contextualize today's fashions within the broader strokes...
As someone who is presenting at his first national conference soon, I was hoping to read through this article and get some good insight. Your list of 4 items amounts to advice that can be summed up as:
1. Old lessons applied to new technology. 2. Future-proofing your skill-set. 3. Analyze today's hard problems and share new solutions. 4. Bold, new ideas that we otherwise wouldn't make the time for.
And this can be summed up in 3 steps:
1. Present a problem. 2. Present solutions to the problem. 3. Solve the problem with the solutions.
Or, more concisely:
1. Solve a problem.
Whether the problem is an old or new problem is irrelevant. And whether the solution is old or new is irrelevant. This is essentially covered in the Angular example.
The result of solving a problem is having to describe the problem. And usually that's best done with a story.
1. Tell a story about solving a problem.
This provides context. And, everyone loves a good war story. This helps you connect (as mentioned in the connect portion of the article). Also, by telling a story, and solving a specific or specific problems, you avoid that general overview. You have to dig into specifics, because your problem was specific.
So, the shortest advice I can sum up is: Tell a problem solving story.
I enjoyed it. As I read, I kept finding myself wanting examples. What talks have you particularly enjoyed? Which talks have exemplified the characteristics you're looking for? Many recordings are available on the web, but even stories about talks that meet one or more of your criteria would have been welcome.
I felt the same way about tech meetups about 18 months ago - myself and my immediate circle of friends just stopped attending them: Watching someone go through the absolute basics of Amazon Web Services or node.js in a real life presentation simply does not provide any value to me, and then to spread it out over a clumsy 35 minute presentation moves it into a "painful" category.
The good parts were in the discussions and questions afterwards but they were often severely truncated because, well, we gotta fit in another half-hour presentation on... unit testing. The "Oh, come talk to me afterwards" rejoinder that genuinely interesting questions got seemed like a cruel tease.
Anyway, recently I took this slightly negative attitude and turned it on its head - what if I ran a tech event with the talk-to-question ratio completely inverted? If the discussions were what we liked, why not create an environment were the talk was simply a quick 5 minute introduction framing an extended, round-table discussion period?
It's still early days, but this has worked extremely well so far. (The result, if anyone's intested, is at: http://www.manytomany.co.uk/)
The good parts were in the discussions and questions afterwards but they were often severely truncated because, well, we gotta fit in another half-hour presentation on... unit testing. The "Oh, come talk to me afterwards" rejoinder that genuinely interesting questions got seemed like a cruel tease.
Anyway, recently I took this slightly negative attitude and turned it on its head - what if I ran a tech event with the talk-to-question ratio completely inverted? If the discussions were what we liked, why not create an environment were the talk was simply a quick 5 minute introduction framing an extended, round-table discussion period?
It's still early days, but this has worked extremely well so far. (The result, if anyone's intested, is at: http://www.manytomany.co.uk/)
I've never really attended any conferences, but I enjoy listening to the Java Posse Roundup exactly because they're discussions, and not just presentations, which seem better fitted for a marketing event than a technical meeting.
Have you considered recording and releasing it as a podcast? Assuming enthusiastic support for the idea, of course.
Have you considered recording and releasing it as a podcast? Assuming enthusiastic support for the idea, of course.
> Have you considered recording and releasing it as a podcast?
Briefly. However, given how we're all seated in a big circle I'm not sure the quality would be good enough. I would also have reservations that the act of recording it would affect what people shared in a negative way.
Briefly. However, given how we're all seated in a big circle I'm not sure the quality would be good enough. I would also have reservations that the act of recording it would affect what people shared in a negative way.
Such a good idea I have joined the list - let me know when the next one is.
Really good idea
Really good idea
Youtube search: 'Quakecon 2013 part 1'. John carmacks keynote from a few months ago. The guy talks and you feel your IQ jump 10 points.
Last year's was pretty good, too. He talked about managing developers and trying to fit code reviews and static analysis into their process. I learned a lot.
Agreed, I think I enjoyed his talk last year more than this year even. Really imparted some ideas I try to apply to how I engineer software.
Thanks for this one. I thought this was going to be a collection of links to great technical talks -- which has value to me -- but was instead surprised with thoughts on what makes a talk great.
I'll definitely be keeping this stuff in mind on future talks I do.
I'll definitely be keeping this stuff in mind on future talks I do.
The biggest problem with the "talk industry", if you can call it that, is the talk selection process. You may have the best talk in the world, but if your proposal doesn't get approved, you ain't giving the talk, no matter what.
The author talks down on giving "tool talks". I agree, those are the most boring talks to listen to, but at the same time, "tool talks" are pretty much the only way to get a speaking slot these days. Those kinds of talks are easy to create a coherent proposal. The more interesting out of the ordinary talks are hard to propose.
The author talks down on giving "tool talks". I agree, those are the most boring talks to listen to, but at the same time, "tool talks" are pretty much the only way to get a speaking slot these days. Those kinds of talks are easy to create a coherent proposal. The more interesting out of the ordinary talks are hard to propose.
Talk selection varies dramatically from one conference to the next (as it should). That said, there are ways to get your content out there without going through a formal CFP process:
* Many conferences have lightning talk sessions, which are much more open to speakers (though they're much shorter slots).
* Local user groups are almost always looking for willing speakers.
* You can record yourself giving the talk and post it online.
* Many conferences have lightning talk sessions, which are much more open to speakers (though they're much shorter slots).
* Local user groups are almost always looking for willing speakers.
* You can record yourself giving the talk and post it online.
That is why a talk like the Bret Victor's Future of programming clicked in so many levels[1]. He wasn't focused on the a specific tool, but a whole new way (old way) of programming.
[1]: http://worrydream.com/dbx/
[1]: http://worrydream.com/dbx/
I prefer those found at http://www.youtube.com/playlist?list=PL4NL9i-Fu15hhYGB-d0hmS...
[deleted]