public talk

How to Fix “Your Conference Presentation”

A few days ago, a PHD Comics cartoon appeared on the Startup PH Facebook group:

While it’s not there anymore (possibly because it deals with academic conferences and not tech/startup conferences and therefore not relevant to the group), I had a voice at the back of my head nagging me to write a blog post on how the strip makes it look like speaking in conferences is a lot harder than it is.

So here’s a blog post on how to prepare yourself for the worst things that can happen when participate in a public speaking engagement.

Previous speaker runs late and eats into your time.

Not really a problem, as almost all of the events I’ve been in perform the laptop setup during the Q&A of the previous speaker. So even if the speaker runs late, it’s not going to eat into your allotted time.

Technical difficulties connecting your laptop.

In my experience, the biggest cause of technical difficulties in laptop setup are Macs. “They just work” my ass.

First off, they need special adapters for video. Your brand new MacBook Air is cool and all, but you’re pretty much screwed if you forgot to bring your mini-DP to VGA adapter.

Second is that non-frequent speakers don’t know how to change the display settings of their Mac to provide the optimal presentation experience. Unless you’re presenting in a Mac heavy venue, don’t expect the technical staff to help you with that.

I’m not saying that if you are using a laptop with a VGA connector, you’re out of the woods already. You still need to know how to change your monitor settings. You can even set your laptop display to 1024 x 768 even before connecting it to the projector to reduce the possibility of getting just a blank screen.

There’s also a plan B for all laptops: Export your presentation to PDF and/or upload it to an online presentation site (eg. SpeakerDeck, Slideshare, or Prezi if you’re feeling fancy). This way, even if your machine fails to connect to the projector, you can borrow another laptop and still be able to have your slides.

“But what about my presentation animations?” you may ask.

Screw animations. Go read Presentation Zen and educate yourself on why you don’t need them.

Forget introducing yourself.

Let me tell you a secret that you’ve probably forgotten once you got that invite to speak on stage:

Nobody gives a shit who you are.

Giving a long introduction about yourself at the beginning of the talk is stupid. For one, if it’s a big conference, you’ll probably have your bio on the programme. On the other hand, if it’s a small conference, you’ll probably be forgotten by the audience by the end of the day especially if you give a boring talk.

And if for some reason you’re a really big name in the field, why introduce yourself to people who already know all about you?

So don’t waste your time talking about who you are. Make a memorable talk and put your website/facebook/twitter/etc on the last slide and people will look you up themselves.

Spend waay too much time describing the outline.
Realize you have 3 minutes left.
Power through the rest of your 30 slides.

Let’s ignore for a moment that tech/startup conference talks don’t have motivation, methodologies and shit.

Anyway, timing problems can be easily be solved by having 2 things: practice and a timer.

Practice is obvious, but too often I see newbie speakers just wing it in front. When I do my talks, I immediately see in the first few practice runs what parts can eat up a lot of time and what parts allow me some time to ad lib. And the shorter and more time-constrained my talks are, the more practice runs I do – this way, I could consider all possibilities and think of backup plans far in advance of the talk.

The timer can be anything: the timer in your presentation software, a pocket watch, or a timer in your handheld clicker/presenter. Combined with practice, you will eventually know what time to expect to reach certain parts of your talk and all you need to do is to adjust accordingly.

Motiva – Annoying audience member interrupts with self-aggrandizing question – tion

You are the speaker. The audience has no control over you. In fact, you are in control of them.

If an annoying audience member (as opposed to good audience members that facilitate interaction and discussion) constantly interrupts your talk, it is your responsibility to put them in their place. It’s up to you whether you’ll humiliate them to shut them up or just tell them to talk to you directly after your presentation – point is, you don’t let them waste your time.

Awkward silence Q&A

Just expect this to happen. Out of the dozens of talks I’ve done these past few years, only about 1 in 10 had engaging Q&As, while only 1 in 3 even had questions for me.

—

Now that wasn’t so hard, was it?

Baguhan Biyernes: Paghahanda sa Hackathon

Kagabi, ako’y nagtalumpati sa WebGeek Pre-DevCup Meetup ukol sa paghahanda para sa mga Hackathon.

Buti na lang nagdala ako ng video camera para di na ako magpakahirap mag malalim na Tagalog ngayong linggo.

Babala: ang susunod na talumpati ay may maseselang tema, linguahe, at droga na hindi angkop sa mga bata o sa trabaho.

(Oo, SlideShare siya at hindi SpeakerDeck. Di kasi lumalabas sa SpeakerDeck ang mga links na linagay mo sa slides.)

What programming language should I learn?

I got to talk for DevCon again last Saturday at STI Makati. Instead of preparing a new talk, I just rehashed an old talk to save time. The new talk is also over at Slideshare.

Anyway, the point of this post is to answer a question posed to me by a student in the Q&A portion of the talk:

Anong programming language ang dapat naming pag-aralan?
(What programming language should we learn?)

Here’s a question I wouldn’t want to hear answered by someone else (i.e. someone who’s also invited to talk to students). The question itself may seem simple, but unless you’ve seen how the industry works as a whole, you’ll probably give a wrong answer.

The traditional answer I don’t want to hear is to give a suggested list of languages based on market demand.

Simply put, this is bullshit. This is the same sort of bullshit that pressures our youth to take nursing courses even though they’re just in it for the money, money that they probably won’t get due to the eventual over-supply of nurses.

So for the student’s question, I gave two answers:

Programming language and platform choice doesn’t matter, because for the most part it’s a business decision.

Yes, I’m talking about steaks and strippers. In a large company, you may be initially hired to work on a single language, but eventually there will be a time where the company will make a business decision to shift technologies, whether due to market pressure or due to a new client. If you focus too much on a language, you will not be prepared for the change and you may end up getting fired or demoted.

In smaller companies or in a freelance setting, language still doesn’t matter, though for another reason: the client will not care about the language as long as you deliver the product.

This leads to the other answer:

Focus on the fundamentals, not on the language/platform.

A common mistake among fresh grads is that they’re confident they know language A or platform B because they were able to make their school projects or theses while at the same time not having their fundamentals down pat. Not only does this make them inflexible in terms of learning new languages, it also makes their work brittle and sloppy.

In other words, a student who has 4 years of school “experience” in Java is nothing compared to a developer who just had learned Java a month ago but has solid fundamentals in OOP.

You might say “Screw learning, I’m just in this for the money!”. But the fact is, there’s this thing called the Python Paradox: developers who are passionate enough to learn more than their peers often end up in higher-earning and less-stressful jobs.

Bottom line: There is no “best” language that you need to learn in order to earn a lot of money. However, if you have good fundamentals, learning the language and platform that the market needs will be much easier for you.

What it takes to be a Web Developer

Did a lightning talk for DevCon DLSU last Wednesday. Not really liking the end result. My decision to deliver it in English is mainly to blame: I wrongly guessed that La Salle students would react better to English than Tagalog (the latter I prefer when giving talks), and all I got from it was having my lack of practice look more obvious.

I think the worst part about my talk was the way how the “sarcastic-whiny-tone” I use in my normal everyday Tagalog creeped into my usually more professional sounding English voice. I’ll probably have to do weeks of voice retraining to eliminate that. =/

Anyway, here is the video of the talk as well as the slides.

What it takes to be a Web Developer

View more presentations from bryanbibat