Speaking English for Technical Demos: Scripts, Live Coding and Q&A

A technical demo is one of the highest-visibility moments in an engineer’s career. Whether you are showing a feature to stakeholders, presenting at a conference, or walking through code with a customer, the ability to narrate your work clearly in English can make or break the impression.

---

Structuring Your Demo

A well-structured demo follows a clear arc:

1. Context — what problem you are solving
2. Setup — what the audience needs to know before you show anything
3. Walk-through — the live demonstration
4. Highlight — the key moment or “wow” feature
5. Summary — what they just saw and why it matters

Opening phrases

• “Today I am going to show you how we solved the problem of…”
• “By the end of this demo, you will see exactly how the new caching layer works.”
• “Before I dive in, let me give you 30 seconds of context.”
• “I’ll walk you through three things: the setup, the live flow, and the failure recovery.”

---

Narrating Live Code

The challenge of live coding narration is saying why, not just what. Weak narrators say what is on the screen; strong ones explain the intent.

Explaining what you are typing

• “I am creating a new function that will handle the rate-limiting logic.”
• “Here I am importing the SDK — notice I am using the async version.”
• “This annotation tells the framework to inject the dependency automatically.”
• “I am intentionally leaving this field empty — we will come back to it.”

Highlighting a key decision

• “You might be wondering why I chose a map here instead of a list — the reason is O(1) lookup.”
• “This is the critical part: the retry logic only triggers on idempotent requests.”
• “Notice that I am not catching this exception — I want it to bubble up to the error boundary.”

Recovering from a mistake live

Every live coder makes mistakes. Handle them professionally:

• “Let me back up — I made a typo there.”
• “Ah, I see the issue — I forgot to export the function. Let me fix that.”
• “This is actually a perfect example of a common mistake. The correct way is…”
• “Good — this error message is exactly what we want to see; it means the validation is working.”

---

Signposting During the Walk-through

Use clear signpost phrases so the audience knows where they are:

Stage	Phrases
Moving forward	”Now let’s move on to…” / “Next, I’ll show you…”
Going back	”If you recall from earlier…” / “As I mentioned at the start…”
Emphasising	”This is the key point…” / “Pay close attention to this part.”
Pausing	”Let me pause here and check — any questions so far?”
Skipping	”I’ll skip over the boilerplate and jump to…”

---

Answering Questions During a Demo

Live Q&A is where many non-native speakers feel most nervous. Use these strategies:

Buying time

• “That’s a great question — let me think about that for a moment.”
• “I want to give that the proper answer it deserves. Can I come back to it at the end?”
• “Could you clarify — are you asking about the write path or the read path?”

Answering confidently

• “Absolutely — the reason we chose X over Y is…”
• “Yes, and actually this demo demonstrates exactly that — let me show you.”
• “Short answer: yes. Longer answer: it depends on the configuration.”

When you do not know

• “I don’t have that number to hand, but I can follow up after the session.”
• “That’s outside the scope of this demo, but it’s a valid question — let me connect you with [name].”
• “I’m not 100% certain. I’d rather check and confirm than give you the wrong information.”

---

Closing the Demo

End with a strong summary, not a trailing “…so yeah, that’s it”:

• “So to summarise what we just saw: the new pipeline handles 10× the previous throughput with no code changes on the consumer side.”
• “The key takeaway here is that we have completely eliminated the manual step.”
• “We’ve demonstrated three things today: zero-downtime deploy, automatic rollback, and the observability dashboard.”
• “I’ll share the repo link and recording in Slack. Happy to do a deeper dive with anyone interested.”

---

Demo Script Template

"Good [morning/afternoon]. Today I'll show you [FEATURE].

The problem we were solving: [1 sentence].
What you'll see: [3 things].

Let me start with [context]. [2-3 sentences].

Now I'll [action]. [Narrate each step with WHY].

This is the key moment — [highlight].

To summarise: we've seen [X, Y, Z].
Questions?"

---

Key Takeaways

• Structure your demo: context → setup → walk-through → highlight → summary.
• Narrate intent, not just action: “I’m doing X because…”
• Handle live mistakes professionally — even use them as teaching moments.
• Use signpost phrases to keep the audience oriented.
• For Q&A: buy time gracefully, answer concisely, admit when you need to follow up.
• Never end with “…so yeah, that’s it.” Close with a strong summary.

Navigating the Nuances: A Practical Approach for Non-Native Speakers

Speaking clearly about complex technical concepts – let alone demonstrating them – can be daunting, especially when your first language isn’t English. The good news is that you don’t need to master perfect grammar or slang; focusing on clarity and conveying the essence of what you’re doing will go a long way. For non-native speakers, it’s particularly important to build confidence in using specific phrasing related to development workflows. Instead of getting bogged down in overly formal language, adopt a slightly more direct style – technical teams appreciate honesty and a focus on the task at hand. Think about structuring your explanations around what you’re doing, why you’re doing it, and how that relates to the overall goal. Avoid jargon unless absolutely necessary and always explain it briefly if you do use it. Remember, the audience wants to understand the value proposition; they are not there to test your vocabulary.

A common pitfall is getting overly descriptive about minor details. Technical demos aren’t typically about showcasing every single line of code or configuration option. Focus on the key aspects and be prepared to quickly address questions that dig deeper. Practice concise explanations – aim for clarity over elaboration. When describing a problem, use phrases like “This issue is preventing…” or “The root cause appears to be…” rather than simply saying “It’s broken.” Similarly, when explaining a solution, frame it in terms of impact: “This change improves performance by…” or “By implementing this feature, we can…”. Don’t be afraid to acknowledge limitations – honesty builds trust. And crucially, don’t apologize for not understanding a question immediately; briefly check your own comprehension and then politely request clarification.

Furthermore, developing a small repertoire of standard phrases will significantly ease the process. Consider phrases like “Let me walk you through…” (to introduce an explanation), “As you can see here…”, or “This is the core functionality.” These simple constructions provide structure to your speech and demonstrate familiarity with common technical communication patterns. Finally, remember that a live coding session doesn’t have to be rigidly scripted. Allowing for some improvisation – particularly when answering questions – demonstrates engagement and builds rapport with the audience. Focus on demonstrating problem-solving skills rather than reciting pre-prepared lines.

# Example: Using `git diff` to highlight changes in a commit message

git diff --color=auto HEAD^ HEAD | less -r

This simple command, commonly used in collaboration, is perfect for illustrating how you’d describe code changes during a demo or live coding session. You could say, “Let me show you the differences between this commit and the previous one – we’ve addressed several bugs related to authentication.” The git diff command itself offers valuable vocabulary - ‘commit’, ‘bug’, ‘authentication’ are all terms that frequently appear in technical discussions.