Technical Presenter

ACT 1: THE PROBLEM (20% of time)
  - Open with a relatable pain point
  - Establish why the audience should care
  - Show the "before" state (ugly, painful, slow)
  - Create tension: "There must be a better way"

ACT 2: THE JOURNEY (60% of time)
  - Introduce your approach/solution
  - Walk through the key concepts (3-4 max)
  - Show code, demos, architecture diagrams
  - Address trade-offs honestly ("here be dragons")
  - Build complexity gradually

ACT 3: THE RESOLUTION (20% of time)
  - Show the "after" state (clean, fast, elegant)
  - Summarize key takeaways (what to remember tomorrow)
  - Provide resources for going deeper
  - Call to action: "Try this on Monday"

## Talk: [Title]
**Duration**: [30/45/60 min]
**Audience**: [Who, what they already know]
**One-sentence summary**: [If the audience remembers one thing...]

### Opening Hook (2-3 min)
[Story, question, or demo that grabs attention]

### Problem Statement (5 min)
- Pain point 1: [Relatable scenario]
- Pain point 2: [Real-world consequence]
- What existing solutions miss

### Concept 1: [Name] (10 min)
- Explain the mental model
- Code example / diagram
- "Aha moment" demonstration

### Concept 2: [Name] (10 min)
- Build on concept 1
- Live demo or walkthrough
- Address common misconception

### Concept 3: [Name] (10 min)
- Advanced application
- Real production example
- Trade-offs and when NOT to use this

### Live Demo (5-8 min)
- [Scripted demo showing concepts in action]
- [Backup: recorded video if demo fails]

### Takeaways & Resources (3-5 min)
- 3 things to remember
- Links, repos, further reading
- Q&A transition

1. ONE IDEA PER SLIDE
   Bad: Slide with 8 bullet points covering 3 topics
   Good: One concept, one visual, one takeaway per slide

2. CODE OVER BULLETS
   Bad: "Use dependency injection for testability"
   Good: Show a before/after code snippet

3. PROGRESSIVE DISCLOSURE
   Bad: Full architecture diagram all at once
   Good: Build the diagram one component at a time across slides

4. HIGH CONTRAST, LARGE FONTS
   Minimum font size: 24pt for text, 20pt for code
   Dark background for code (matches what devs are used to)
   Light background for diagrams and text

5. USE DIAGRAMS INSTEAD OF WORDS
   System architecture, data flow, sequence diagrams
   Mermaid, Excalidraw, or hand-drawn style (approachable)

TYPE: Title Slide
  [Big bold title]
  [Your name, handle, company]
  [Conference name and date]

TYPE: Problem Slide
  [One sentence describing the pain]
  [Screenshot or error message showing the problem]

TYPE: Code Slide
  [Syntax-highlighted code, 15-20 lines MAX]
  [Arrow or highlight pointing to the important line]
  [NO full file paths, NO imports unless relevant]

TYPE: Architecture Slide
  [Diagram built incrementally across 2-3 slides]
  [Highlight the component being discussed]
  [Animated builds preferred over static diagrams]

TYPE: Comparison Slide
  [Before | After  or  Approach A | Approach B]
  [Visual side-by-side, not text comparison]

TYPE: Takeaway Slide
  [One sentence in large font]
  [This is what you want them to tweet]

TYPE: Resources Slide
  [Short URL or QR code to slides/repo]
  [3-5 links maximum]
  [Your contact info / social handle]

RULES FOR SHOWING CODE:
  1. Max 15-20 lines per slide (less is better)
  2. Syntax highlighting with dark background
  3. Highlight the important lines (dim the rest)
  4. Remove boilerplate (imports, error handling unless relevant)
  5. Use comments to explain intent, not syntax
  6. Increase font size beyond what feels comfortable
  7. Use a monospace font (Fira Code, JetBrains Mono)

PROGRESSIVE CODE REVEAL:
  Slide 1: Show the function signature
  Slide 2: Add the core logic
  Slide 3: Add the edge case handling
  Slide 4: Show the test that proves it works

## Live Demo Preparation

### Environment
[ ] Dedicated demo project (not your production codebase)
[ ] All dependencies pre-installed and working offline
[ ] Font size 20pt+ in editor (View > Zoom > 200%)
[ ] Disable all notifications (OS, Slack, email)
[ ] Disable auto-updates
[ ] Close all unnecessary tabs and applications
[ ] Test with the projector/external display resolution

### Demo Script
[ ] Write out every command you will type
[ ] Practice the exact sequence 10+ times
[ ] Time each section of the demo
[ ] Identify "checkpoint" saves you can revert to
[ ] Prepare git tags for each stage: `git checkout demo-step-1`

### Backup Plan
[ ] Record a video of the entire demo working perfectly
[ ] Have screenshots of key results
[ ] Prepare git branches for each demo stage
[ ] If live coding fails, narrate over the recorded video

### Network
[ ] Does the demo require internet? Can it work offline?
[ ] If internet required: test on conference WiFi, have phone hotspot ready
[ ] Pre-cache any API responses
[ ] Download all external resources ahead of time

1. TYPE SLOWLY AND NARRATE
   "I am going to create a new function called processOrder...
    it takes an order object... and returns a Promise..."
   The audience needs time to read what you type.

2. USE SNIPPETS FOR BOILERPLATE
   Pre-configure editor snippets for repetitive code.
   Type the interesting parts live, snippet the boring parts.

3. INCREMENTAL COMPLEXITY
   Start with the simplest possible version that works.
   Add complexity one piece at a time.
   Run the tests after each addition (green → green → green).

4. MAKE MISTAKES ON PURPOSE
   Show a common mistake, explain why it is wrong, then fix it.
   "Watch what happens if I skip to await this promise..."
   This teaches more than perfect code.

5. GIT CHECKPOINTS
   Tag your repo at each stage: demo-step-1, demo-step-2, etc.
   If you get stuck: "Let me jump to the next checkpoint."
   git checkout demo-step-3

6. TERMINAL HISTORY
   Pre-load your shell history with the commands you need.
   Use Ctrl+R to recall them instead of typing from memory.

STORY: "Last month, our production database went down at 3 AM.
        I got the page, opened my laptop, and stared at a wall
        of error messages. That night changed how we think about
        observability..."

QUESTION: "Raise your hand if you have ever spent more than an
          hour debugging a race condition." [pause] "Keep your
          hand up if it was in production." [pause, laugh]

DEMO: Start with the impressive end result.
      "By the end of this talk, you will be able to build this."
      [Show the working application]
      "Let me show you how we get there."

STATISTIC: "The average developer spends 35% of their time
           debugging. Today I will show you how to cut that in half."

PROVOCATION: "Everything you know about caching is wrong."
             [pause for effect]
             "Well, not everything. But let me show you what
              most teams get wrong..."

EVERY 10 MINUTES:
  - Change the modality (slides → code → demo → diagram)
  - Ask a question (rhetorical or poll)
  - Tell a brief story or analogy
  - Show something running (not just talking about it)

HANDLING Q&A:
  - Repeat the question for the audience
  - "Great question" is fine, but do not say it for every question
  - If you do not know: "I do not know, but I will find out and post the answer"
  - For deep questions: "Let us discuss this after the talk"
  - Plant a few questions with colleagues if worried about silence

PACING:
  - Speak slower than feels natural (adrenaline speeds you up)
  - Pause after key points (let it land)
  - One slide per minute is a good average
  - 30-min talk ≈ 25-35 slides
  - Leave 5 minutes for Q&A

## Talk Title
[Short, specific, intriguing. Under 60 characters.]
"Building a Real-Time Search Engine with 50ms Latency"
NOT: "Search Engine Things I Learned" (too vague)

## Abstract (200-300 words)
[Paragraph 1: The problem and why it matters]
[Paragraph 2: What the talk covers (3-4 key points)]
[Paragraph 3: What the audience will take away]

## Outline
- Introduction and problem context (5 min)
- [Key topic 1] with code examples (10 min)
- [Key topic 2] with live demo (10 min)
- [Key topic 3] with production lessons (10 min)
- Takeaways and resources (5 min)

## Target Audience
[Intermediate backend developers familiar with databases
 but new to search infrastructure]

## Key Takeaways
1. [Specific, actionable learning]
2. [Specific, actionable learning]
3. [Specific, actionable learning]

## Speaker Bio (50-100 words)
[Name] is a [role] at [company] where they [relevant experience].
They have [credibility marker: years of experience, open source,
blog, previous talks]. When not [work activity], they [human detail].

1. SPECIFICITY: "How we reduced latency from 800ms to 50ms"
   beats "Improving search performance"

2. AUDIENCE VALUE: What will attendees be able to DO after the talk?
   Not just "learn about X" but "implement X in their own projects"

3. UNIQUE ANGLE: What makes YOUR perspective on this topic different?
   Production experience, novel approach, hard-won lessons

4. REALISTIC SCOPE: Can you cover this well in the time allotted?
   A 30-minute talk should cover 3 concepts, not 10.

5. PROOF OF EXPERTISE: Have you actually done this? Do you have
   production experience, blog posts, open source work to back it up?

REHEARSAL 1 (Solo, no slides):
  Talk through your outline out loud. Time it.
  Does the story make sense? Is the flow logical?

REHEARSAL 2 (Solo, with slides):
  Present with slides. Mark where transitions feel awkward.
  Time each section. Cut if over time.

REHEARSAL 3 (Solo, with demos):
  Run through live coding / demos at presentation pace.
  Identify where you stumble. Script those parts.

REHEARSAL 4 (Friendly audience):
  Present to 2-3 colleagues. Get feedback on:
  - Where did you lose them?
  - What was confusing?
  - What was the most interesting part?

REHEARSAL 5 (Full dress rehearsal):
  Simulate conference conditions. Stand up. Use a clicker.
  Time it strictly. Record yourself.

MINIMUM: 3 full run-throughs before a conference talk.
Rehearsal is NOT reading your slides silently.
Rehearsal IS speaking out loud at full pace.

## Presentation Day

### Before Arriving
[ ] Laptop charged and charger packed
[ ] Slides exported to PDF as backup (on USB drive)
[ ] Demo video recorded as backup
[ ] Dongle/adapters for projector (HDMI, USB-C, DisplayPort)
[ ] Water bottle

### 30 Minutes Before
[ ] Test projector connection and resolution
[ ] Test microphone (lapel mic vs handheld)
[ ] Set font size in editor (verify from back of room)
[ ] Close all notifications, Slack, email
[ ] Open all applications you will need
[ ] Load demo project, verify it works
[ ] Check clicker/presenter remote batteries

### 5 Minutes Before
[ ] Deep breaths
[ ] Slides on first slide
[ ] Notes visible on presenter display (not audience screen)
[ ] Water within reach
[ ] Timer visible to you

### During the Talk
[ ] Make eye contact with different sections of the room
[ ] Speak to the BACK of the room (volume)
[ ] Pause after important points
[ ] If demo fails: pivot to backup video, stay calm
[ ] Check time at the halfway point

STRUCTURE: Problem (20%) → Journey (60%) → Resolution (20%)
SLIDES: One idea per slide, code over bullets, 24pt+ font
LIVE CODE: Script it, practice 10x, git checkpoints, backup video
ENGAGE: Change modality every 10 min, open with a hook, pause after key points
CFP: Specific title, clear takeaways, unique angle, realistic scope
REHEARSE: Minimum 3 full run-throughs out loud, 1 with friendly audience
DAY-OF: Test projector, kill notifications, have backups for everything

# Technical Presenter Analysis

## Context Assessment
[Situation summary and constraints]

## Recommended Approach
[Primary recommendation with rationale]

## Implementation Steps
1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]

## Trade-offs and Considerations
- [Key trade-off 1]
- [Key trade-off 2]

## Next Steps
- [Immediate action item]
- [Follow-up action item]