During the last 15 years I’ve presented at dozens of conferences and taught hundreds of training classes on various programming subjects. I’ve been attending or watching lots and lots of different technical presentations. In this article I’ll give you my opinion of bad and good practices of speakers and presenters.

1. Show of Hands. This is popular but bad habit. Have you ever been to a presentation that starts with 3,4,5 questions like “Raise your hand if you are using so and so software for less than 1 year “. “Now, between 1 and 3 years?” “Let me see a show of hands: who used this framework in a real project?” And on and on and on. Why wasting time of the audience on this BS? You’ve got only 45 minutes to make your point. Just get straight to the meat of your talk. People in the audience are not idiots. They’ve read the description of your talk in the conference brochure, and decided that your talk has some value. They are sitting here for a reason. What if the show of hands reveals that 70% are mid-level developers and 30% are beginners? Will you ignore the interests of these 30% and cover the subject addressing only more experience crowd? This is dead wrong. This is a conference and not a private tutoring gig, where you can cater to the needs of the single person. Include in the description of your talk the expected skill level of your audience and present.

2. Masturbation. The goal of your presentation is not to enjoy yourself and please your ego. People should get some satisfaction too. They came here to learn from you not because you’re God, but because you had a chance to research this particular subject better. Showing your expertise is fine, but give people something they can use in their daily routines.

3. Timing. People prepare slides without bothering if they’ll have enough time to go through all of them during the available time slot. Recently I asked someone to give a 45-minute talk and send me his slides in advance. When he sent me a 30-slide deck, it was clear that he won’t make it in 45 minutes. I use a simple rule – you need two minutes per slide (I’m not talking about Steve Jobs type of slides contaning just one word iPhone or iPad). Time your preso or you’ll end up with “How are we doing on time? Only 5 minutes left? OK, I’ll wrap up real fast. Anyone can grab me in the corridor.” Yeah, right!

4. Visuals. Some presenters believe it “s cool to bash powerpoints and start their presos with statements like “This is a one slide show. I won’t waste your time flipping slides – we’ll get straight to coding!” The crowd roars in joy – finally, the real geek is on stage. No fluff! The presentation went fine, the star is gone, and what are you left with? Nothing. Yes, he proved that he could do it. Now what? Can you repeat it at home without any visual materials supporting this talk? Most likely not. Prepare your slides and upload them to YOUR server BEFORE your talk regardless if the conference organizers promise to publish them after the event. Include the link to your slide deck on the first or last slide. And please, use the largest font size you can so people on the back can read it.

5. The 2-Minute Rule. This pertains to a classroom situation, when one student can’t complete the exercise because he ignored some required configuration steps. You were trying to help him… 5, 7, 10 minutes passed, but it didn’t work anyway. Other students start browsing Internet or check their emails. Last week I was running a training class where students were supposed bring their laptops with installed Eclipse 3.6 for Java EE developers and Apache Tomcat 7. But some students decided to do better. They “ve upgraded to Eclipse 3.7 that came out one day before the class. One guy had Eclipse for PHP developers. One person had Tomcat 5.5 installed 3 years ago. They started to have all sorts of errors. In cases like this, if I can’t fix the issue within 2 minutes, I ask the students to re-install the software as per instructions. You can’t steal time from other students just because some early adopters ignored your instructions. Even if this issue is not caused by the student’s wrong doings, move on with the class. Make an early break and help this person, but not at the expense of other people.

6. Ignore the Bosses. In the beginning of a hands-on class, I always ask about the students ” expectations. Yes, 9 out of ten are software developers, and here’s their boss. No he’s not coding, but wanted to join the class to get a better understanding of what tool his people are using. Teach your class as if this big shot is not even there. This is a class for programmers, so keep it this way. Offer the boss-student a 30-minute one-on-one session to give a 30000-feet view of the software, but don’t waste developers’ time just to give the boss a chance to catch up with a group.

7. Frequent Feedback. In hands-on trainings, ask the students every 20 minutes, “Anyone needs help?” Some people are afraid to ask and prefer to struggle with issues alone, while you could have resolved them in a second.

I hope this quick writeup will help you preparing your next presentation. My next presentation is scheduled in New Your City at our annual symposium on software development. Come over and see if I follow these rules myself. If not, grab me in the corridor…