As a seasoned technical speaker at the Telerik Academy, I received an invitation for one of my favorite technical events – DevReach.
Despite the fact that I am too biased with Open Source and normally try to stay away from Microsoft and other companies relying mostly on closed source products, it’s always helpful to see how other experts think, what sort of issues do they have, how does a language evolve etc. Also, the folks from the Microsoft field have decent training programs (just as we have Sun’s certificates, now Oracle’s in Java and the one PHP-related Zend exam).
Tips For Technical Speakers
I regularly watch videos of other technical speakers and attend different conferences, and occasionally I find it curious to why people do one thing or another. Call it a “common sense”, but I see no reason in doing something or acting in some way.
It’s my 4th DevReach after helping with the organization of the first one in 2006 (I guess) and I’ll outline several mistakes I’ve noticed during some of the talks.
When you have a 30-60-90 min talk long pauses are annoying. During a conversation a pause often means that a question has been asked, and it causes confusion during a talk.
There are normal pauses at the end of a sentence, or during a real question, otherwise frequent pauses increase the tension. The session should be a story with beginning, explanation and conclusion, just like an essay.
A session has two purposes – to teach and inspire. Technical speakers who don’t inspire are labeled as boring or not helpful, this is not the reason for them to be invited to conferences with 50, 250, 1000 attendees.
Dozens of Questions
A trained professional can play with the audience and ask questions here and there, it’s fine.
But asking continuous questions with multiple answers is weird, people are shouting different responses, audio recording after the session is either blurry, or only the pauses are heard (no responses either). “Raise your hand” questions are fine to get some attention back to the talk.
We all know the “demo effect” with “Shit, that used to work 1 hour ago”. It happens. But if that happens to all of your demos, than probably something is deeply wrong. Try to bring your notebook with the right setup and make sure that your environment is in tact.
“Just for the Demo”
Teaching people on best practices is quite important. Occasionally, for the sake of the demo, one might do a “not really the standard” sort of demo, but it should be avoided and the best practice should be explained and eventually provided after the session in the demo (uploaded on GitHub for example).
Many professional speakers avoid text at all, maybe except for a slide title/heading. Even if you need to add some demos and bullets, make sure they are short, strict, clear and visible for the back rows.
If you really need your audience to read that, make sure it’s possible. This reflects the color scheme as well. If you want to provide more text for the people, prepare another text or presentation with text but in addition to the original one.
Try to provide as much details for what sort of audience is the talk appropriate for. Bringing the “big guns” for beginners or wasting 80% of the session time for 101 issues with full room of experts is just bad planning.
Lack of/Useless Examples
No matter what your subject is, you need to provide examples.
Elaborate on why a session important for the audience, where does it apply, or how can people benefit from it in practice. Code samples, use cases, real use scenarios are necessary. Don’t skip that part or provide useless examples.
There are various issues one could notice during a session, but that’s a gist of common troubles for beginning speakers. Try to use your common sense, imagine being in the hall, what would be awesome to see from a technical speaker and what would be annoying.
Ask in advance what sort of audience attends if you are not aware of the fact, and find out how many people (averagely) would attend a session etc.