As I’ve been preparing for my talks at DevConnections next week, it’s struck me how talk preparation is one of those things that is immensely enjoyable yet incredibly frustrating (read: time-consuming) at the same time. 

Why me?

What’s so hard about giving talks?  Well, being in a programmer role, this is one of those things that most people dread, and for good reason: it’s a lot of work and there’s a lot of pressure. But perhaps more importantly, you don’t get a lot of practice doing it.  And this turns out to be incredibly important both in general and specific cases.

How did you become a good programmer?

Nobody ever sits down at a computer and instantly is a master programmer.  Skill in programming, like any discipline, is learned, molded, and practiced, typically in a relatively relaxed environment where you get to collaborate with more experienced people who can give you feedback about your code. In my opinion, this is one of the reason open source projects tend to do so well.  If you didn’t have to practice to get good, well, congratulations, you’re some kind of super genius, but I would say most people aren’t like you :).

So What?

At this point, you’re probably wondering what this observation has to do with giving technical presentations.  Well aside from reading a list of tips, which is really useful and great, there is the underlying principle of getting better at anything.  How do you build a better coder?  I like to think of it in terms of three major categories:

• Mentoring from experienced people: Code reviews, chatting with your managers and senior developers
• Practicing: Getting hands on experience doing what it is you want to get better at, so in this case, writing code
• Learning: This is an obvious but important point.  Practice and mentoring are worthless unless you learn from them and do things differently.  Don’t make the same mistakes.  Learn new things.  Keep getting better.  My piano teacher always said: don’t trick yourself into thinking that doing something wrong 100 times is practice: it’s not.  It’s better to do it right even just once.

What about my talks?

And so dear reader, if you’re still with me at this point, we come now to the crux of the matter.  Most programmers have never had experience giving technical presentations, and thus never really had a change to practice or get good at it.  Even for those of us who have, how often do you do it? That’s why Scott’s Post is so relevant: a lot of us simply don’t do presentations often enough to remember all of these things and get better at them.  I myself am guilty of this, and find that every time I have to do talks I need to rebuild some of my expertise, and this takes some time.

Fine, but why do I care? Let Scott do the demos.

Technical presentation skills are highly effective and transferrable to your day to day work.  The core discipline is to communicate technical information as effectively as possible, and we all do this in our day to day work.  More recently, our QA team has started recording bug repro videos for the developer team to use.  Getting good at these is a great stepping stone to improving your presentation skills: nobody wants to watch a video of a bug report where you are saying “uhm” and “errrrr” all the time.  I’ve also heard good things about Toastmasters as a way to get better by practicing, but YMMV.

Okay I believe you.  How do I get better?

By now you probably know the answer.  Practice.  Like crazy.  But look for opportunities to practice.  Whether it’s giving a small presentation to your team, or maybe to your boss, or even getting good at shooting small videos, these things add up to being a better presenter.  One of the things that helped me greatly was doing joint talks at first, with James Senior and also with Simon Calvert.  I got to see first hand how experienced speakers prepared for talks, structured content, and kept the audience engaged.

My biggest three tips are:

1. Keep the audience engaged and involved.  James Senior taught me this one first hand, and watching Scott Hanselman present has really driven this point home for me.  People aren’t there just to learn from your content, they are there to be entertained and kept awake.
2. Provide compelling content.  Tell a story.  Nobody wants to see you go up there and rattle on about a boilerplate list of new features when they don’t see how it could map to their day to day work.  Don’t expect anyone to make the leap on their own.  Show them.
3. Practice.  Know your talk and your content.  Time your slides.  Set up dry runs.  Go over the talk until you know it by heart.  It’s funny because you would think that this leads to a scripted delivery (and to be fair you should be careful that you aren’t doing this).  On the contrary, I’ve found that it allows you to be flexible when questions do pop up –> you can recover much easier and also go off the beaten path if you sense the audience is interested. 

I do have to credit Simon Calvert with teaching me the importance of #3.  I think few people put in the tremendous effort to deliver a phenomenal show for our customers.  For all the blog posts and tweets and books I have and could have read, none of them resonated with me more than sitting down with a mentor and learning, apprentice-style, from a master.  I encourage you all to find these people in your circle and follow in their footsteps.  Happy practicing!