
Great Technical Talks - searls
http://blog.testdouble.com/posts/2013-08-29-great-technical-talks.html
======
searls
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.

~~~
jasonlotito
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.

------
lamby
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/](http://www.manytomany.co.uk/))

~~~
icebraining
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.

~~~
lamby
> 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.

------
brador
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.

~~~
Finster
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.

~~~
prawks
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.

------
scrabble
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.

------
freework
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.

~~~
bscofield
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.

------
ibudiallo
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/](http://worrydream.com/dbx/)

------
MrZongle2
I prefer those found at
[http://www.youtube.com/playlist?list=PL4NL9i-Fu15hhYGB-d0hmS...](http://www.youtube.com/playlist?list=PL4NL9i-Fu15hhYGB-d0hmSWD1fcIvLvn1)

