Demo or Die Trying: A Guide to Screen-share Survival

So you’ve agreed to do a demo. Buckle up: it’s basically a stand-up comedy where the code plays clown. Demos matter because, yes, someone actually cares what you built (and they expect it to work). This is your chance to show off your genius, justify that two week sprint, or at least avoid getting fired for the day. “If it compiles on the first try, a nyawawa (demon) is probably involved.” Odhiambo. F Why Demos Matter (Even if You’d Rather Be Coding) Show Your Masterpiece: A demo lets you share what you’ve built. Managers and coworkers finally see your code in action instead of trusting your rambling status updates and confluence edits. I know you already know that. Get Real Feedback: Ever wonder if anyone actually cares about that one obscure feature you spent a week on? A demo answers that (and gets you useful questions instead of blank stares). Avoid the “But Why?” Questions: It’s better they see it now than ask “So… can it do X?” in front of everyone later. That’s how meetings turn into horror shows. Demonstrate Progress: Think of it like a report card or timecard. You get to prove you weren’t just binge-watching cat videos all sprint. Plan and Structure Your Demo (Or Prepare to Wing It and Swoon) A good demo has a flow. Randomly clicking around in your IDE is not it. Think of your demo like cooking a meal for guests: Appetizer (Intro/Context): Set the stage quickly. What problem are you solving, or what new feature are you unveiling? Keep it punchy. Main Course (Live Code/Features): Highlight the meaty part. Show one or two key features or code paths step by step. Keep it simple, don’t deep dive into every branch of the code. Plating (Transitions): Have an outline or script. Know which files, branches, or windows you’ll open. Silence notifications, hide embarrassing tabs, and pretend your browser bookmarks are private. Dessert (Summary/Next Steps): End with a flourish. Recap what you showed and tease what’s next. Aim to leave them craving the next course, or at least satisfied with tonight’s meal. Remember each part shouldn’t run as long as your backlog aims for clarity, not a brain-melting feature dump. Know Your Audience: Tech Geeks vs. Mere Mortals Tech Geeks: Your tribe wants details. Feel free to geek out with diagrams or code snippets (just don’t read every semicolon aloud). Casual Crowd: Ditch the acronyms. Explain the why over the how. If they don’t know Docker, don’t dissect Kubernetes; just say it’s a way to run stuff reliably. Everyone: Use analogies and humor. If eyes glaze over, ask a question or toss a joke. (Treat your audience like goldfish: too much detail and they’ll swim away, but feed them the right tidbits and they might stay.) Stay Flexible: If your audience shifts (managers walk in, or half the room dozes off), be ready to pivot on the fly. Maybe say, “I’ll simplify that!” and adjust on the go. Demo Horror Stories (Fictionalized Folklore) The NullPointer Nightmare: Bob starts with untested code. Crash! A giant red NullPointerException appears. “It’s a feature!” he claims, sweat and all. Lesson: always test, and sanitize your error handling. Wi-Fi Apocalypse: Sarah’s demo needs internet. Mid-pitch, the office Wi-Fi takes a vacation. Cue eternal loading. She ended up narrating a slide deck for 20 minutes, calling it a “conceptual preview.” Forgotten Passwords: Mike shares his screen… and forgets to hide his password manager. Now passwords fly everywhere. Note to self: lock up secrets before screen-sharing! Microphone Mutiny: Denil answers questions beautifully… until he realizes nobody heard him because his mic was muted. The audience gave a standing ovation to his mime act. Auto-Update Armageddon: Lee kept talking while an auto-update progress bar slowly marched across his screen. Eventually it rebooted. (Tip: turn off updates before you demo, unless you love forced naps.) These tales are dramatic exaggerations, of course, but every dev has at least one horror story like them. Moral: expect the unexpected and always have a Plan B. Common Mistakes to Avoid Winging It: No one believes a flawless, impromptu demo. Even rock stars rehearse. Write a script or at least bullet-point your steps. Data Dump: Bombarding everyone with 47 menu items and endless settings is boring. It’s the demo equivalent of reciting your grocery list. Ignoring Time: A two-hour demo is murder (especially if you’re solo). Practice with a timer. If your audience starts doodling, you’ve officially lost them. Neglecting Setup: "Unknown host", permission pop-ups, or missing libraries can kill you. Prep your environment thoroughly. Maybe even reboot and try again. Forgetting the Audience: A monologue of code and jargon only impresses you. Make eye (or webcam) contact, invite questions, and connect the dots verbally. Pro Tips for Demo Domination Practice Religiously: Run through the demo alone and with someone else. You want to squash hiccups now, not on stage. Keep Visual Aids Handy: A

May 22, 2025 - 07:10
 0
Demo or Die Trying: A Guide to Screen-share Survival

So you’ve agreed to do a demo. Buckle up: it’s basically a stand-up comedy where the code plays clown. Demos matter because, yes, someone actually cares what you built (and they expect it to work). This is your chance to show off your genius, justify that two week sprint, or at least avoid getting fired for the day.

If it compiles on the first try, a nyawawa (demon) is probably involved.” Odhiambo. F

Why Demos Matter (Even if You’d Rather Be Coding)

  • Show Your Masterpiece: A demo lets you share what you’ve built. Managers and coworkers finally see your code in action instead of trusting your rambling status updates and confluence edits. I know you already know that.

  • Get Real Feedback: Ever wonder if anyone actually cares about that one obscure feature you spent a week on? A demo answers that (and gets you useful questions instead of blank stares).

  • Avoid the “But Why?” Questions: It’s better they see it now than ask “So… can it do X?” in front of everyone later. That’s how meetings turn into horror shows.

  • Demonstrate Progress: Think of it like a report card or timecard. You get to prove you weren’t just binge-watching cat videos all sprint.

Plan and Structure Your Demo (Or Prepare to Wing It and Swoon)
A good demo has a flow. Randomly clicking around in your IDE is not it. Think of your demo like cooking a meal for guests:

  • Appetizer (Intro/Context): Set the stage quickly. What problem are you solving, or what new feature are you unveiling? Keep it punchy.

  • Main Course (Live Code/Features): Highlight the meaty part. Show one or two key features or code paths step by step. Keep it simple, don’t deep dive into every branch of the code.

  • Plating (Transitions): Have an outline or script. Know which files, branches, or windows you’ll open. Silence notifications, hide embarrassing tabs, and pretend your browser bookmarks are private.

  • Dessert (Summary/Next Steps): End with a flourish. Recap what you showed and tease what’s next. Aim to leave them craving the next course, or at least satisfied with tonight’s meal.

Remember each part shouldn’t run as long as your backlog aims for clarity, not a brain-melting feature dump.

Know Your Audience: Tech Geeks vs. Mere Mortals

  • Tech Geeks: Your tribe wants details. Feel free to geek out with diagrams or code snippets (just don’t read every semicolon aloud).

  • Casual Crowd: Ditch the acronyms. Explain the why over the how. If they don’t know Docker, don’t dissect Kubernetes; just say it’s a way to run stuff reliably.

  • Everyone: Use analogies and humor. If eyes glaze over, ask a question or toss a joke. (Treat your audience like goldfish: too much detail and they’ll swim away, but feed them the right tidbits and they might stay.)

  • Stay Flexible: If your audience shifts (managers walk in, or half the room dozes off), be ready to pivot on the fly. Maybe say, “I’ll simplify that!” and adjust on the go.

Demo Horror Stories (Fictionalized Folklore)

  • The NullPointer Nightmare: Bob starts with untested code. Crash! A giant red NullPointerException appears. “It’s a feature!” he claims, sweat and all. Lesson: always test, and sanitize your error handling.

  • Wi-Fi Apocalypse: Sarah’s demo needs internet. Mid-pitch, the office Wi-Fi takes a vacation. Cue eternal loading. She ended up narrating a slide deck for 20 minutes, calling it a “conceptual preview.”

  • Forgotten Passwords: Mike shares his screen… and forgets to hide his password manager. Now passwords fly everywhere. Note to self: lock up secrets before screen-sharing!

  • Microphone Mutiny: Denil answers questions beautifully… until he realizes nobody heard him because his mic was muted. The audience gave a standing ovation to his mime act.

  • Auto-Update Armageddon: Lee kept talking while an auto-update progress bar slowly marched across his screen. Eventually it rebooted. (Tip: turn off updates before you demo, unless you love forced naps.)

These tales are dramatic exaggerations, of course, but every dev has at least one horror story like them. Moral: expect the unexpected and always have a Plan B.

Common Mistakes to Avoid

  • Winging It: No one believes a flawless, impromptu demo. Even rock stars rehearse. Write a script or at least bullet-point your steps.

  • Data Dump: Bombarding everyone with 47 menu items and endless settings is boring. It’s the demo equivalent of reciting your grocery list.

  • Ignoring Time: A two-hour demo is murder (especially if you’re solo). Practice with a timer. If your audience starts doodling, you’ve officially lost them.

  • Neglecting Setup: "Unknown host", permission pop-ups, or missing libraries can kill you. Prep your environment thoroughly. Maybe even reboot and try again.

  • Forgetting the Audience: A monologue of code and jargon only impresses you. Make eye (or webcam) contact, invite questions, and connect the dots verbally.

Pro Tips for Demo Domination

  • Practice Religiously: Run through the demo alone and with someone else. You want to squash hiccups now, not on stage.

  • Keep Visual Aids Handy: A diagram or slide helps ground the explanation. It’s your safety net if the live bit stalls.

  • Silence All the Things: Mute Slack, email and random notifications especially the WhatsApp Web notifications. The worst is a cringe meme or boss’s personal message popping up mid-demo.

  • Backup Plan: Have a pre-recorded demo video or slide deck ready if live fails. It’s like having a stunt double for your code.

  • Keep Your Cool: If something breaks, laugh it off and move on. Even fictional coder Zen Masters recommends: “If my demo crashes onstage, at least I’ll go out in a blaze of glory.”

Keep it short, snappy, and a little snarky. You’re the star, but try not to steal the show from your code. Wrap up confidently: “That’s the gist, questions?” and mean it. You’ve survived the bugs and the spotlight. Now go forth and have no fear, “Even if you're not ready for the day it can't always be night” . In the world of demos, you’ll either dazzle them or give them one heck of a story for the next stand-up meeting. Either way, it’s memorable.

Written with ❤️ by a human (or so I claim). AI detectors say it's 99.99% machine-made..those snitches. Don’t believe them. I’m just a very caffeinated developer with suspiciously good grammar.