Flatiron School Presents: Seven Ways to Fail-Proof Your First Technical Presentation

All developers will eventually have to present what their working on—whether internally to their teams or in front of a big group at a conference. So we put students in our Web Development and iOS courses through the presentation ringer early on. All of them have to present at a Flatiron Presents Meetup at least once while they’re here. It might be intimidating for beginners, but so far, they’ve done a fantastic job at conquering their nerves and constantly raising the bar for technical presentations here.

If you’re brand new to technical presentations—as many of our students are—you’re in luck. There are tons of resources out there for you. We’re partial to Zach Holman’s speaking.io. But here are a few more tips we give our students for securing an applause-worthy performance.

1. Choose a small, specific topic

Whether you’re talking for two minutes or 20 minutes, pick something small and focused. If you’re relatively new to this, you’re probably not going to be breaking new ground or presenting the future of the internet. Be honest with yourself and choose a topic that you can actually present well in the time allotted to you, maybe something interesting you’ve learned and applied or a demo of an app you’ve built.

2. Tell a concise story

Every piece of your presentation should fit into a coherent, concise narrative—like how you built an app to solve a problem or created a Ruby to gem to learn how to create Ruby gems.

Once our students have picked a topic, we advise them to keep it laser-focused on the story they’re telling. Anything that doesn’t clarify or add value to it should probably be left out. We’re pretty sure you don’t need that introductory TED Talk or a 10-minute-long movie clip, no matter how insightful they are. A small, specific topic and a super focused explanation will help you go in depth on your subject matter without going overtime or confusing people.

3. Try picking a topic you don’t know

Don’t be afraid to present something you don’t know. Talks are a great opportunity to learn a new thing. Regardless of whether you have 3 months or thirteen years of experience, if you’re unsure about a technology, preparing for a talk could be a great way to learn it. By the time you’re prepared enough to give a presentation on creating Ruby gems, you’ll probably be able to create one.

One word of caution: by the time you step up to present you should be an expert on what you’re presenting. Know enough not only to present but also to field potential questions. If you want to build and demo an app to get experience with Backbone.js, you don’t have to be a Backbone expert, but you should be an expert in the context of your app, your decisions, and your thought process.

4. Use code samples wisely

Code samples can bring a lot of practicality and context to your presentation—but only if they’re relevant and if your audience can read them. You don’t have to present every code snippet you’ve ever written. Pick the ones that add value to your presentation and flesh out the story you’re trying to tell. Once you’ve picked out your samples, make them more readable with syntax highlighting. Grab an RTF plugin like this one or this one.

5. Make the most of your demo

If you plan on demoing something you’ve built, fantastic! Demoing your work should be the most exciting part for you and your audience—the part you’ve worked hardest on and that you’re most proud of. So make the most of it.

Like the rest of your presentation, your demo should be part of a coherent narrative. Do not demo everything you’ve made—just the interesting, functional parts. When you’re deciding what to show, pick the parts of your project that solve a problem or add value to your presentation, the shortest path to making your point.

It’s also important to keep your demo as controlled as possible. Even experienced developers run into game time bugs. Click all of the buttons you plan on clicking beforehand and don’t add unexpected variables by letting people touch your app during your presentation.

6. Keep the debugging to yourself

If your demo fails, don’t fret. This has happened to folks like Steve Jobs and DHH and pretty much everyone else, too. But if you’re new to this, don’t try to spend minutes that feel like hours fixing your app in front of everyone. It’s hard enough to demo software live, and it’s even harder to fix your code under pressure. Just let it go. Or even better (as Zach Holman suggests), arm yourself with a backup demo. Try using QuickTime to record your screen as you demo your app before your presentation. This way, you’ll have handy video evidence that your app once did what it was supposed to do.

7. Don’t let screwing up get you down

Here’s something you might not realize: everyone in the audience wants you to succeed. Unless you’ve made a few enemies throughout your tumultuous rise to the podium, no one is sitting there hoping you’ll bomb, waiting to revel in your failure. On the contrary, they want to be entertained and informed. You don’t have to imagine them in their skivvies to feel confident that they’re on your side.

If you don’t do so well, try not to worry. It’s possible that no one even noticed. And if they obviously did, acknowledge your mistake gracefully and move on—laugh or even take a bow to break the tension. If you can muster the courage to move on, your mistake won’t keep you from having a great time. Finally, (and most importantly) remember that presenting is only going to get easier if you do it over and over again. It just takes some experience, and that includes a fail or two.

For more on Flatiron School presentations, you can usually find our students and alumni presenting at events like New York Tech Meetup, Rails Conf, Ruby Conf and New York Tech Meetup again. If you’re in New York can also see their presentations in person. Flatiron Presents Meetups happen every Tuesday right here on campus. RSVP for the next one.

Disclaimer: The information in this blog is current as of October 22, 2014. Current policies, offerings, procedures, and programs may differ.