Live Coding

Summarized using AI

How to Talk to Developers

Ben Orenstein • June 25, 2013 • Portland, OR

In this talk titled "How to Talk to Developers," Ben Orenstein, a veteran conference speaker, shares practical techniques for improving presentation skills, particularly for developers. Acknowledging that nearly every developer will eventually present to their peers, he outlines strategies that can significantly enhance their influence within their teams and communities. Throughout the presentation, Orenstein emphasizes the importance of being engaging and entertaining rather than just informative. He implements this by incorporating real-time activities such as calisthenics which help energize the audience from the start. Here are the key points discussed during the talk:

  • Engage Early: Orenstein advocates for doing something unique within the first minute of a talk to catch the audience's attention, such as physical activity or a surprising request.
  • Hierarchy of Interests: He stresses that it’s essential to be more interesting than the internet to capture and maintain the audience’s attention, hence the mantra: "It’s more important to be entertaining than informative."
  • Show, Don’t Tell: Orenstein discusses the technique of live coding and demos over slides to convey information better, asserting that live action offers more depth than static slides.
  • Body Language: He shares tips on effective body language to ensure confidence while presenting; maintaining an open and relaxed posture can significantly impact audience perception.
  • Handling Nervousness: Orenstein provides insights on dealing with nerves before and during a talk, including power posing to boost confidence and the importance of not pre-apologizing for perceived shortcomings in the talk.
  • Q&A Strategies: He suggests asking for questions while maintaining open body language to encourage engagement and facilitate a more dynamic discussion post-presentation.
  • Avoiding Common Pitfalls: Orenstein highlights anti-patterns in speaking, such as appearing unexcited, using unreadable slides, and failing to engage the audience as they might expect.

In conclusion, Ben Orenstein’s presentation emphasizes that effective communication involves connecting with the audience through engaging delivery rather than just presenting dry content. By focusing on an entertaining approach and employing practical techniques discussed, developers can not only improve their presentation skills but also enhance the overall experience for their audiences, making them more likely to absorb and retain the information shared.

How to Talk to Developers
Ben Orenstein • June 25, 2013 • Portland, OR

Nearly every developer will be asked to present to his or her peers at some point. Those that do it well will tend to have an outsized influence on their team, company, and community.
This talk will demonstrate (mostly by example) the straightforward techniques for giving excellent presentations, from a veteran conference speaker and teacher.
Topics to cover include:
* Phrases that turn your audience against you.
* Basic body language tips that affect perception.
* How to be more interesting than the internet.
* The power of live coding and demos.
* Being funny without resorting to reddit memes.
* How to get plenty of questions during Q&A.
* How to get an unfair amount of talk acceptances (aka 'Bribing conference organizers').

Help us caption & translate this video!

http://amara.org/v/FGaB/

RailsConf 2013

00:00:15.980 Good morning, RailsConf! How's everyone doing? I figured we would try something crazy and start on time. For those of you who have seen me give talks before, you can probably guess what's about to happen. My name is Ben Orenstein, and I work at ThoughtBot. I would love it if you could all stand up, please.
00:00:50.870 Oh man, it’s hard to see everyone! I'll take the stage. Would you please do a set of 12 air squats with me to get the blood pumping a little? An air squat is simple; you just squat down and stand back up. Let’s do 12 together. Ready? One, come on, feel the burn... That’s 12! Awesome! Now, would you please reach your hands up in the air like you don't care? Scratch that stretch, get a little taller! Keep your abs tight and bend to one side for a nice stretch. Now return to the middle and stretch to the other side, feeling that stretch without making the pain face! Excellent! Now, turn to your neighbor, thank them for coming, say, 'Hey neighbor, how's it going?' and shake their hands. Awesome! Go ahead and take your seats.
00:02:05.890 So, this talk is 'How to Talk to Developers'. If you know me, you’ll understand there’s no way I could just give a purely mental talk. I am a very practical guy and like to focus on examples and real-world scenarios. There's no way I could just sit here and talk to you for 40 minutes about giving talks.
00:02:18.580 What I'm going to do instead is give you several lightning talks that will cater to your short attention spans. As we go through the week, I'll present these talks, and then I'll discuss the techniques I used in them, mixing in some meta-discussion as we go. In the best-case scenario, if you learn nothing about speaking, you'll hopefully at least learn something from the lightning talks. Worst-case scenario, you might learn a little bit more than that.
00:02:40.390 The first thing we’ll talk about is the Law of Demeter. Can I have Chad, Joe, Kayla, John, and George join me on stage, please? Gentlemen, would you stand over here? These are my colleagues. Say hi, colleagues! Now, can we have you in that order: Chad, then Joe, then Kayla, then John and George? Will you come over here, please? I’m going to keep John in reserve; he’s my special guy.
00:02:59.220 The most important thing to know about the Law of Demeter is that everyone will argue about how to pronounce it. Some people say 'Demeter' and others say 'Demeter.' I’ll switch between the two just to maximize the trolling. So, these good-looking gentlemen are objects in my system. I have built a system where Chad is an object, Joe is an object, Kayla is another object, and John is yet another object. Now, John is the master of time; he knows what time it is! It is exactly 10:30. Perfect! Now, Chad wants to know the time.
00:03:41.630 However, because I wasn't aware of the Law of Demeter, I have incorrectly encoded the information. Chad knows that he should ask Joe to ask Kayla to ask John what time it is. So, he says, 'Hey Joe, please ask Kayla to ask John what time it is.' Joe knows what to do, asks Kayla, and then she asks John, who tells them the time. However, I didn’t code John very well. So, it turns out it’s 10:30-ish. Chad gets the information back, and that’s great, but they have just broken Chad.
00:05:14.520 Now, I will say, thank you, Kayla, for your help; you may go sit down. George comes in; sorry, Caleb, but you've just been refactored. George is my new replacement for Caleb. He functions better than Caleb did. The problem is, I have broken Chad. Now, when Chad asks Joe to ask Caleb to ask John what time it is, Joe will say, 'No problem,' but then we will get an exception, and that makes Chad sad. Chad is broken.
00:06:00.330 The reason Chad is broken is because of structural duplication in the system. That’s what the Law of Demeter addresses. It’s about avoiding structural duplications. It says not to encode in your objects knowledge about how the entire system is wired together. What we need to do is refactor because we broke Chad. We have to change Chad's internals. Now, instead of asking Joe, Chad may ask Joe, but Joe isn’t going to let him know what he’s doing.
00:07:00.300 Chad turns to Joe and asks, 'What time is it?' and Joe has no clue. Instead, Joe will turn to George and say, 'What time is it?' Then George will whisper in John’s ear, 'It’s still 10:30, ish according to me.' This allows Chad to actually not be broken anymore because if I want to swap out George or even John again, it doesn’t bother Chad. He remains intact.
00:07:53.180 Let’s give a big clap for these guys. That’s the Law of Demeter: don’t encode structural knowledge about your system in objects because then you have coupling. Chad knew exactly how to get the time. All I want to know is who he should ask. That person should then obscure how they're getting the time, and that way, you can swap out components and reduce coupling.
00:08:18.130 So, that's it! That’s the first lightning talk. Now let’s discuss some meta stuff. Right off the bat, I did two things you probably haven’t seen at this conference. We started with some light calisthenics to get the blood flowing and to excite you. That was intentional; it’s critical to grab people right away. Your first 30 to 60 seconds set the tone.
00:09:20.570 Notice that my introduction was a single sentence: 'My name is Ben Orenstein; I work at ThoughtBot, and I’d like you all to stand up.' By the end of my first introductory sentence, something unusual has already occurred; I want your attention right from the start. Too often, speakers start with traditional introductions that involve slides discussing themselves or their company. Instead, hitting the audience with something engaging right away leads them to focus.
00:10:35.420 The main thesis of this talk is this: it’s more important to be entertaining than informative. Bored people don’t learn anything. No matter how good your information is, if it’s not interesting, your audience won't learn a thing. That’s not to say you should only focus on entertainment; you need balance but start with the interesting bits. Hold people’s attention; it's challenging since you’re competing with the entire internet.
00:11:25.240 Let me share a quick story. I was at a conference we held for college students in Boston, teaching them basic software engineering principles. Nick Courant gave an introductory talk on TDD, which I already understood, but his delivery was captivating. He kept me engaged for the entire eight minutes even though I learned nothing new. Sandi Metz once said, 'People enjoy a story; they don’t even know it's art.' It’s true!
00:12:17.720 Every newspaper article begins with a high-level summary in the first sentence, followed by more details in the next. Each paragraph builds on the previous. The structure allows an editor to cut the piece at any point and maintain a coherent story. You’ve already heard my thesis, which means if you zoned out, you still know the one most important message. There’s still more valuable content coming up.
00:13:46.030 A common principle in object-oriented programming is 'Tell, don’t ask'. For talks, I abide by 'Show, don’t tell'. Let me demonstrate a few interesting enhancements to my Vim productivity.
00:14:12.300 Is anyone here a fan of Vim? It’s cool to see! Let’s dive in. First, I learned about relative numbers, which adjust according to your cursor position. This means no more eyeballing where you are; for example, if I have to navigate four lines up, I can simply tell Vim to go up four lines without counting actual line numbers. Super helpful!
00:15:28.540 Another handy tip is to use leader commands in Vim. They significantly improve your speed with repetitive tasks. I watched a live coding session with Aaron Patterson and Corey Haines, where Aaron asked to commit code, and I realized how often I’d leave the editor to do so. So I set up a leader command to commit my current directory with a work-in-progress message and push it—always staying within Vim.
00:16:48.710 Lastly, while at a conference, you might find yourself without internet. That’s the perfect time to explore Vim's built-in help feature. Go to :H, scroll down, and explore the section on editing effectively. You might discover a lot of helpful information in there, especially about how to be more efficient.
00:17:58.540 Circling back to some meta-advice about live demos: I love them. There’s something extraordinarily powerful about demonstrating live coding as opposed to showing slides. This is because slides are typically just staged photographs of static content, while live demos are like showing a video of the action; it conveys far more information than a slide could.
00:18:39.610 Now let’s briefly touch on body language. Many new speakers struggle with this. Good body language includes standing tall and looking comfortable and confident. However, people often revert to closing their arms or adopting a poor posture under pressure. Your hands naturally seek a place, and for some, that can be awkward. Maintain a relaxed posture: arms bent at about 90 degrees is an excellent default.
00:19:50.690 Let me share a story about my very first job in programming. I applied for an entry-level position, totally inexperienced, at a company willing to train me. It was an age-old medical software company where they suffered from a severe case of 'Not Invented Here' syndrome. This company wrote everything in-house, including their operating system and programming language, which I found astonishing.
00:20:32.730 They were still creating mail clients, to-do list applications, text editors, and languages, ultimately leading to an overwhelmingly complex environment for me to work in. One example is when HP approached them in the early '90s to create a handheld device for bedside ordering. These engineers decided to write a new language that was incredibly cryptic—using capital letters for local variables and limited global identifiers, resulting in a nondescript, highly convoluted program.
00:21:42.670 I quit that company in search of better environments but took screenshots of this proprietary language before I left. I wanted people to believe that such a language really existed. As I show you this code, just keep in mind that everything on the surface appears impossible to decipher!
00:22:32.190 Here is a snippet of that programming language. I know that you can’t read it, but all I can say is it was written in a confusing way and incredibly challenging to maintain. I eventually left and moved on, but the experience was certainly an eye-opener on what not to do when coding.
00:23:12.540 Let’s talk about stories briefly. People love stories, particularly about the speaker. It’s akin to The Daily WTF; audiences enjoy hearing about embarrassing coding failures. In my case, at ThoughtBot, we recently introduced a new platform called Learn Prime, combining workshops, screencasts, and ebooks into a subscription model. It’s a fantastic resource that I think would benefit many!
00:23:53.050 Dealing with nerves is essential for speakers; it’s a common challenge. First, accept that nervousness is inevitable. Even I get nervous before every talk! To manage this, I embraced calisthenics at the beginning of my presentations, which aids not only in energizing the audience but also helps me channel my adrenaline into something productive. If you struggle with massive reactions—sweaty palms, dry mouth—consult your doctor about beta blockers to lessen your fight-or-flight response.
00:24:49.880 An interesting natural method is called 'power posing,' popularized by Amy Cuddy. This technique involves body positioning that conveys confidence. Her research found that those who posed confidently were judged more favorably during mock interviews than those who did not. So, if you look back on any photos upon entering this room, you might see me doing this powerful pose, as it helps me feel more confident!
00:25:51.470 Another effective strategy for managing nerves is identifying a 'nodder' in the room. This is someone that will respond positively to your statements, helping you build confidence throughout your talk. If you're really anxious, consider having a friend sit nearby and nod enthusiastically at your points; it can make you feel much more at ease.
00:26:48.600 Now let’s touch on a few anti-patterns that detract from effective talks. First is a lack of enthusiasm. Nothing beats authentic excitement! If you're speaking about something you're not passionate about, it shows—don’t do it! Second, avoid creating slides with small fonts or low-contrast colors. It’s crucial that your audience can read every slide even from a distance.
00:27:34.430 When a speaker tends to pre-apologize, they instinctively lower the audience's expectations for their content. Statements like, 'This is my first talk,' or 'I'm sort of nervous' do not set the right tone. Just start strong instead! When asking for questions, resist filling in the silence; give your audience a moment to digest before interjecting.
00:28:30.830 So, here’s a brief summary before we wrap up. Don’t aim for last slots in a conference day; people are tired by then. Additionally, don’t give talks in large rooms, as they detract from the intimacy and connection you can build with your audience. Aim for smaller spaces—500 people in a room that seats 450 creates excitement rather than disappointment.
00:29:58.520 Now, remember to go with the flow and have fun! For instance, if it’s someone’s birthday during your talk, like Jason’s today, why not harness that energy? Let’s sing 'Happy Birthday!' If you’ve never had 400 people sing to you before, now’s your chance! Not only is it a fun engagement tactic, but it also builds a sense of community among the audience.
00:31:47.330 I want to teach you the correct way to sing happier birthday! There’s a trick; everyone stands and picks a starting pitch. Keep your body posture tall and lifted while singing. Now, let's take a deep breath, letting your expansion involve your diaphragm, and remember to open your soft palate, as this will help project your voice.
00:32:37.660 Timing and volume are also critical. Focus on building up to the last phrase—happy birthday to you! That was not too bad. Now, let's try it again and only use our full voices this time. My task is to ensure we all sing in perfect tune together. It’s a collaborative effort, so I want to hear from each of you!
00:33:39.270 That’s what I did! I effectively drafted all of you into the new RailsConf chorus, which has been a fun twist on the way we usually engage in technical talks! Thank you all for participating, and remember, whether it’s coding or singing, enthusiasm and energy can turn any presentation into a valuable experience.
Explore all talks recorded at RailsConf 2013
+93