🎙 Develpreneur Podcast Episode

Audio + transcript

Successful Presentation Tips for Developers: Effective Demo Strategies

In this episode, Rob and Michael share tips and strategies for effective presentations and demos, including preparing for unexpected situations and using technology to streamline the process.

2024-06-07 •Season 21 • Episode 29 •Presentations and Demos for Developers •Podcast

Summary

In this episode, Rob and Michael share tips and strategies for effective presentations and demos, including preparing for unexpected situations and using technology to streamline the process.

Detailed Notes

In this episode, Rob and Michael discuss the importance of being prepared for presentations and demos. They share tips on how to test audio and video settings, use a backup plan, and avoid making changes to code during a presentation. They also discuss the benefits of using a clickable demo or mockup instead of live code. Additionally, they touch on the importance of using technology to streamline the presentation process, such as using Zoom or other video conferencing tools. Throughout the conversation, they emphasize the need for developers to be flexible and adaptable in the face of unexpected situations.

Highlights

  • Bring all necessary equipment to presentations
  • Test audio and video settings beforehand
  • Use a backup plan, such as printed materials or a USB drive
  • Avoid making changes to code during a presentation
  • Use a clickable demo or mockup instead of live code

Key Takeaways

  • Be prepared for presentations and demos
  • Use technology to streamline the process
  • Avoid making changes to code during a presentation
  • Use a clickable demo or mockup instead of live code
  • Test audio and video settings beforehand

Practical Lessons

  • Use a backup plan, such as printed materials or a USB drive
  • Take screenshots of code or mockups instead of live code
  • Use comments in code to make it easier to follow
  • Test code beforehand to avoid typos and mistakes

Strong Lines

  • Be prepared, not just for the presentation, but for the unexpected
  • Use technology to streamline the process, but also be prepared for technical issues
  • Avoid making changes to code during a presentation, it's better to have a backup plan

Blog Post Angles

  • 5 Tips for Effective Presentations and Demos
  • How to Use Technology to Streamline Your Presentation Process
  • The Importance of Being Prepared for Presentations and Demos

Keywords

  • presentations
  • demos
  • developers
  • technology
  • streamlining
Transcript Text
Welcome to Building Better Developers, the Develop-a-Noor Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing our season 21 of the Building Better Developers, Develop-a-Noor Podcast. This episode, we're going to talk about presenting and demos and not as much about, maybe not so much about the technical stuff, although we will get into that a little bit, but more about the non-technical things and the things that you will do that will shoot yourself in the foot if you don't go at it with the right attitude or if you assume because assume, you know, what they always say is if you assume something, you're going to look like crap in front of your boss or somebody like that. So we're going to talk about that this episode. But first, I got to introduce myself because that's what I do. I am Rob Brodhead. I am one of the founders of Develop-a-Noor, also the founder of RB Consulting. You can check us out on the web and all that kind of good stuff. Basically Develop-a-Noor is where we build better developers. RB Consulting is we take those developers and we go out and we solve problems and leverage technology to simplify, automate, integrate all that good stuff. But the other thing we do is we talk to Michael all the time and I'm actually using his name. Shoot, I was going to make him introduce more, but I'll at least tease that that's his first name. Go ahead and finish up that introduction. Hey, everyone. My name is Michael Milosz, another co-founder of Develop-a-Noor. I'm also the founder of Envision QA, where we have small to mid-sized businesses and small health care clinicians build software and test software for existing applications. So I want to talk about presentations and demos because we actually beforehand, for those of you that are here watching us, hey, you already know this, so sorry to be repetitive, redundant, but we were talking about some of the things we've run into, particularly from a technical point of view when we've talked about microphones and some things like that. One of the things that, and that's what triggered this episode, was how many times I have gone to a demo of some sort where I have either, I am presenting, I am the presenter or I am watching somebody present. And this includes demos, it includes speakers, usually not a huge place, but if you go to like meetups or smaller conferences, like the side rooms and conferences and stuff like that, and actually even back to college days when somebody would come in that was a guest speaker or something like that, any time you go into an environment that you don't own, that you don't know, then there are some things that you need to be aware of. And these things are going to help you speed your way through it and make it look smooth, even if honestly, even if it's not, because you're going to get the stuff smoothed out before you have witnesses to the event. Now, one of the things is bring, get all of your stuff that you're going to use to present, get there early, depending on how it is, usually at least like 15 minutes, usually more like a half hour to 45 minutes early. I would say early enough, think about what if you show up and you have to run to the store to get something? What kind of timeframe do you need to be able to do that and still be able to do your presentation? I have literally had that happen. I have seen that happen many times where somebody gets there and it's like, oh, the remote that you really need for your presentation, it had batteries and they're dead. And so you got to run down the corner store or wherever it's at and go get batteries just so because nobody has spares. It's things like that that happen. It is Murphy's law where if it can go bad, if it can go wrong, it will. This includes things like you're going to go to a very modern place with modern tools and you're going to find out that the only way that they have to connect from your video to your laptop is, I don't know, like jumper cables or something weird like that. They're going to have something that's just so backwards or so brand new that it's like, oh my gosh, I didn't even think about this. I will give you a really quick example and not to like put somebody on the spot, but hey, I just recently got married and we the night before put all our audio stuff together and we had it like we figured it out. It was somebody. It was a whole somebody else's place and it was such a mess that it was just like, okay, I'm going to take a phone, iPhone, common iPhone. We're going to plug it in. We're just going to run the music through that. Awesome. Worked, tested out. Everything's great. Next day, come in and the guy that's the DJ had not done that. He didn't show up beforehand. He had a newer iPhone. So where we had everything we needed for the old, you know, non-USBC or whatever, the original Apple or the most recent one back Apple plug, he didn't have that. And so we ended up spending, they ended up actually spending time trying to find a way to get a dongle into that. And finally they had to find somebody else's phone and copy stuff over and it was just, it was a mess. It was all because assumptions because it's like, oh, it should be fine. Don't ever trust anybody else to do it. Use your equipment. Check it out. Before I throw this over to Michael, I will go one more step outside of that technical side. If you're doing a demo, if you're doing a, especially if it's a sales presentation or if it's a class that you're teaching, one, make sure you have your slides, whatever they are. Make sure you check your slides for things like, I don't know, spelling errors and stuff like that. Just run through the whole, make sure you're running through them, verify that they're okay. Make sure that they're in order. Make sure that you didn't lose some, make sure that you have, I always have like a folder that I make specifically for that beforehand. And then when I get there, the first thing I do is I open that folder and make sure that all the stuff I need is in there. So you're not searching your drive for it. You're not suddenly like, oh crap, I put it on Dropbox and it disconnected on me this morning or something like that. It doesn't hurt to even have it like on a little USB drive that you could plug in as a backup and don't change anything. Especially if it's code, like seal that code off, put it somewhere so it is standalone, so that you don't touch it and nobody else touches it. Because I don't know how many times I've gone in to do that, like last minute change and everything's wrong. And it just ruins the whole thing. Now I'm going to take a deep breath and I'm going to let Michael share his experiences and his thoughts on this, because I know you, sir, have done this a few times as well, especially with your educational background. I bet you got some great stories. Well, it's funny because, you know, I was at your wedding and me and Renee both commented that, you know, your bag of tricks is sitting at the house with the dogs. Otherwise you could probably fix their problem in about five minutes. Given the problem, I don't go anywhere without my bag of tricks. So I'm one of those, I get not paranoid people that, you know, I'm afraid I'm going to go into a situation for a presentation, a meeting, whatever. And there's been way too many times where things break or it doesn't work. Or to Rob's point, the code broke or changed and now you can't present. So a lot of things that I've learned over the years have, let me give you a few little tidbits. So to build on Rob's point, you could be like me and basically go buy a cookie cutter, everything that you always need with you and just carry it with you. There's enough of these little pocket or even wallet size kits you can get for a lot of your USB cables, micro HDMI, HDMI, and they're all USB plugins. It's kind of really cool. But if you don't want to go that route, if you're going into like a call presentation, we kind of talked about this before jumping into the podcast. You always want to make sure that you are familiar with the tools that you're using. So for instance, we're using Zoom to record our call here. So the cool thing with this is Zoom has its own capabilities at the start of every call. You can say, test my sound settings, test my video settings. And you click that and then you can make sure you can hear the audio coming out of the call. You can also test your mic, make sure you can hear yourself coming out of your mic. Behind that though, so that is more of a software adjustment tool to using your internal audio and microphone. Within your operating system or whatever machine you're using, there are machine level applications for your specific operating systems, Windows, Mac, whatever. And you need to also make sure that those are configured correctly as well. Because if you have your sound turned way down on your mic at the hardware level, it doesn't matter how good your software is, it's not going to really be able to boost your audio that well. That being said, if you go to the hardware direction where you get like these external microphones like me and Rob use, or use your desktop audio, you again need to make sure you have the right drivers. You need to make sure that the software that comes with those works. And if you're using like soundboards and things of that nature, you want to make sure that you mark where your settings are for your calls. Because if someone comes in and changes that, now you're going to be spending hours trying to get that set up again. Now to carry this one step further, so you take from the setup approach. Anytime I go anywhere, like Rob said, if you have a presentation or something like that, make sure you have a backup. So typically I will always print whatever I take with me. I still have paper copies. But I also carry an iPad, which also has a downloaded copy of the document. And I have my MacBook with me, which has a physical copy of the file. In case both of those fail, I also have a backup on my keychain. I have a USB little thumb drive that just sits on my keychain in case of emergencies. I always throw a file on there if I'm going to go present. Right there, you now have four places where you have your presentation. So if you fail at that point, it's out of your hands. There's just nothing you can do. But if you at least have the paper and you can't plug in, you can still have your notes. You can still talk and present the material to people. And you should be okay to do that. Now, if you're in a big auditorium, you might lose your voice because you're going to have to shout very loud if nothing works. But hey, it can be done. Carry that over a little bit more with the presentation. So you talked about the code. Don't make changes to the code. With the presentation piece, what I've had to do in the past is if you have code that is kind of a work in progress or a proof of concept, sometimes it's better to take screenshots of that code or mockups of that code and throw it into something like PowerPoint or something like presentation where you can actually mock it up, make it look user-friendly. And if you're really good at it, you can do it in such a way that your slides go with the way you click the application. So if you click a button to change the screen, the next slide would basically be click, oh, hey, this is what it will look like. So you can still make an interactive presentation as if you're doing a real live demo. So that's another way you can kind of set yourself up for success in case something fails or the application isn't ready. And the last thing I'll kind of note on before I pass it back to you, Rob, is your machine. So I mentioned that I have multiple copies and backups. I also carry my bag of tricks with me because in my situation, everything I have is Mac based. So what's cool about that is if you use iCloud or again, you keep backups of your copies and everything, most of your USB or even cloud-based streaming apps work. So in my case, I actually also carry with me a Google Play Stick. I carry an Amazon Stick and I also have an Apple TV I carry with me when I travel. In those situations, if you don't have anything to plug into for a presentation, you can potentially stream it to whatever it is that you're working on. So if you have a TV, you can just plug it into a TV and stream it to a TV across the room. So that's another way that you can actually save yourself some hassle if you're walking into an unknown situation. If you know they have TVs, then bring your own streaming service so you can actually stream to those TVs. Rob, I'll pass it back over to you. Those are a lot of great points. I do want to hit on having a PowerPoint or something like that. Even if you're doing a code demo, unless a key part of the demo is showing it working live, I would go with a clickable demo. I've done it off of an existing application because you don't want to spend a lot of time essentially reinventing the wheel to have a demo. But what I have done that has worked really well is I've gone in and I've done just take screenshots of an application and then I can set it up so I can just, I've done it as simple as just HTML pages. It's a clickable image and when you click on it, it doesn't matter that you clicked on that button or not, it's going to go to the next page because I can control that. I'm not going to let anybody else play with it. I'm good. And I know exactly what it's going to do. I don't care about the data. And that is the nice thing about a clickable demo is being able to stick to the story that you want to tell. That is a bonus one is don't ever, if you're on a live application of any way, form or fashion, don't ever go with the somebody in the audience says, Hey, could you do this? Either say, take a look into it or yes, we can, but that's not part of this demo or I'll talk to you offline or something like that. Because as soon as you do it almost always, that's going to be the thing that breaks your entire application, breaks your demo, throws a whole thing, just like it goes completely off the rails. So still, and honestly can lose you confidence from your audience because you're showing, you're telling them a story and saying, this is how it works and this is all this good stuff and this is all great until you like, they say, well, hey, try this. You're like, oh yeah, we can do that. And then it, bam, you just lost credibility because you thought you could. And even if you say, I don't know that we can, but hey, let's try that. That's awesome. If you're in the middle of like a testing demonstration and you want to be able to test this thing and you want to beat on the whole point is to break it. Awesome. If that's not your goal, then don't take that on. Even if you are a hundred percent sure, which you're never, you're 99.99999% sure that that's going to work. If you haven't tested it, if you haven't verified it, if that is not part of your script, do not go off script. It is like, it is one of those things. It's like a golden rule for politicians when they're out there stumping. That's why it's speech, speech, speech, you know, like script, script, script. They script everything, do the same thing, because when you start going off script, it's real easy to get off track and to, and to break something. So I want to, I'll give you last words here. Well, I want to take on to that because when we were teaching, so if you are presenting or teaching code, something else that's very beneficial, especially for the recipient or the student as they're watching. And it's also good for you for post presentation is copy all your code into notepad, into a text file, and then streamline your application that you're demoing to just comments. So now as you're walking through, don't type the code, go copy it from your text and paste it in at each step and then walk through what you're doing. This helps address two things. One, none of us write code well when someone's standing over our shoulders. We have typos, we have grammar mistakes, we just get nervous and things just go off the rails. Two, you might forget something and having the code right there, it's like, oh yeah, I need that. So you don't miss a step. So now you don't break your train of thought or the conversation as you're walking through the presentation. What are your thoughts on that Rob? I agree. That's, I think that is the best way to help yourself out is to have comments, either have it commented out. If you want to do something, it's a progressive kind of lecture where it's like, okay, first we're going to do these couple of lines and then we're going to do these things. I always either have it in a step one, step two, step three code file, so I'm executing different files, or I have had some, especially if you've got block comments, that makes it easy because it's like, okay, now this is uncommented. Now I'm going to uncomment these three lines and then you can talk through it as you go. And then the other thing, which is honestly what I've done probably more often than anything is I'll have my full code in one file and then I'm basically rebuilding it. But like you said, I'm not going to type it. This is way too easy, especially if you're in a language that is case sensitive or space sensitive or anything like that. It is way too easy to get like type one thing off or you'll mistype a variable name or something and you go through the whole thing and then you end up spending sometimes you know, 20 minutes chasing down a typo. Just, you know, be safe, like test that code, write it beforehand, test it, make sure. And that's honestly, I think that is one of the biggest things that I see. If you go out to really any tutorial bootcamp education site, go to, you know, Udemy or anything like that. If you look the code, the comments on anything that's code related, almost always you're going to get people, they're in a bunch of, it doesn't work, code doesn't work, code doesn't work. And sometimes it's very simple. It's like, hey, your code doesn't work because you forgot this. Now, sometimes it is more important. It's like the code doesn't work because you didn't, you forgot to mention that there's this other thing you did, or there's this way that you need to set up your environment. So that's why, you know, that's why we, when we do this a lot of times, start from scratch of like, okay, there's somewhere along the way. Here's where we built that environment. Now it may be, you know, six months down the road, we're teaching stuff, but it's like, if you're struggling, remember, go back to day one. Here's the notes. Here's what you need to do to get it right. What you need to do to get it right is give us feedback, is let us know info at developernor.com. Check us out at developernor.com. Check us out on developernor on our YouTube channel. Go out to Twitter slash X. It's developernor. You can go out to Facebook. We have a page. You go to LinkedIn and we have a page. If we don't, we're going to have to build one real quick, but I think we have one. And just however you can get reach out to us, feel free to do so. We would love to hear back from you. We would love to get feedback and just let us know what kind of problems you're running into, because yeah, we obviously have problems every week and some we can talk about on the air. So we have a lot that we can go through, but it is always helpful to also see what you guys are running into and where we can help you out and talk through some of these, because it's always like you get a couple different voices. The next thing you know, you've got a situation like, Ooh, I didn't think about that. I thought it was just me, but no, it's actually everybody that runs into that. That being said, we'll let you get back to whatever it is that you're doing. And hopefully it is working on becoming a better developer like the rest of us. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Newer Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.