Chapter 15 · Reps

The Thirty-Minute Case — Reps

← Back to Chapter 15

Chapter 15 — Reps

Ten reps. Each one produces a piece of the talk you deliver next week. Do them in order and the deck, the demo script, the fallback recording, and three timed rehearsals exist by Friday. Skip them and you will build all four on Sunday night, badly.

Ground rules

  • Your project, your artifacts. Every rep pulls from your own repository. If a rep asks for a number and you do not have one, that is a Week-13 documentation gap surfacing — go fix the artifact first. It is worth 50 percent.
  • Feature freeze. You tagged v1.0 last week. This week you may fix a defect. You may not add a feature. Not one.
  • Everything gets committed. Deck source, run sheet, demo script, rehearsal log, and Q&A prep all land under docs/presentation/ in your repository, with dated commit messages.
  • Out loud, on a timer. Silent rehearsal does not count. Reading in your head runs about 30 percent faster than speaking, which is exactly how a 27-minute plan becomes a 34-minute talk.
  • Log the hours. Every rep goes in the hours log with an honest number. Fifteen weeks of honest weights and measures; do not start rounding now.
  • AI is a sparring partner, never a ghostwriter. It may attack your talk, tighten a sentence, and generate hostile questions. It may not write a slide you cannot source or a claim you cannot defend.

Warm-up: compression

Rep 1 — The one-sentence answer

Write what your software is, for whom, in one sentence of 25 words or fewer, with no jargon and no adjectives.

BAD  (41 words, zero information):
"PantryPilot is a modern, full-stack web application leveraging a robust React front end and
a lightweight backend to provide users with a seamless and intuitive experience for managing
their household food inventory."

GOOD (21 words):
"PantryPilot tells a household what food is about to spoil and what they can cook from
what's already in the kitchen."

Now the test: read your sentence once, out loud, to a person who has never heard about your project — a roommate, a parent, anyone. Then ask them to say it back.

Produce: the sentence, in docs/presentation/one-liner.md. Reflect: What did they get wrong when they said it back? That error is the exact word you must replace. Write both versions and the fix in two sentences.

Rep 2 — Build the run sheet

Copy code/talk-run-sheet.md into your repository as docs/presentation/run-sheet.md and fill all ten rows: minutes, cumulative, slide numbers, the key line you must say even if you are behind, and a KEEP / CUT marker.

Constraints: total ≤ 30:00, questions ≥ 3:00, demo ≤ 7:00, and at least two sections marked CUT.

Produce: the completed run sheet, committed. Reflect: Which section did you most want to give more time to, and which section paid for it? Name the tradeoff in one sentence. If nothing had to pay, your total is over thirty and you have not finished the rep.

Block one: the deck

Rep 3 — Mine your repository for three numbers

Open your repository and pull three real numbers you will put on evidence slides. For each, record the number, the artifact it came from, and the date it was measured.

| Number                       | Source artifact                    | Measured |
|------------------------------|------------------------------------|----------|
| 44 of 47 tests passing       | docs/tests/results-2026-11-14.md   | 11-14    |
| 4 open defects (1 major)     | docs/defect-log.md                    | 11-15    |
| 197 hours across 15 weeks    | docs/hours-log.csv                      | 11-15    |

Rule: if you cannot name the file and the date, the number does not go on a slide.

Produce: the three-row table, in docs/presentation/evidence.md. Reflect: Was there a number you wanted to show and could not source? Say what it was and what measuring it properly would take. That sentence is a legitimate Q&A answer next week.

Rep 4 — Rewrite your worst slide

Build a first-draft deck from code/slide-outline.md. Then find your worst slide — the one with the most words and the fewest facts — and rewrite it using the decision-slide pattern: what you chose, what you rejected, the constraint that decided it, what it cost you, and one piece of evidence.

Keep both versions side by side for this rep.

Produce: the before slide and the after slide, pasted into docs/presentation/slide-audit.md. Reflect: Count the adjectives you deleted (“robust,” “seamless,” “scalable,” “modern,” “powerful”). What did each one turn into — a number, a constraint, a rejected alternative, or nothing at all? The ones that turned into nothing were never carrying meaning.

Rep 5 — The six-foot test

Put the deck in presentation mode, stand six feet back from the screen, and read every slide aloud. Anything you squint at fails. Fix it: bigger type, fewer words, higher contrast, or the slide gets split in two.

Produce: a one-line note per fixed slide in docs/presentation/slide-audit.md. Reflect: How many slides failed on the first pass? The usual answer for a first deck is between a third and a half. What is the pattern — font size, contrast, or word count?

Block two: the demo

Rep 6 — Write the demo script, then run it cold

Copy code/demo-script.md to docs/presentation/demo-script.md. Fill the header (target, account, seed command, reset command, network needed, time budget) and write six or seven numbered steps, each with the exact action, the exact expected result, a seconds budget, the requirement ID it satisfies, and the failure fallback.

The bar for a step, in both versions:

BAD:
- show the expiring soon page
- maybe show the recipe thing if it works

GOOD:
| # | Do exactly this      | Expect exactly this               | Sec | Satisfies | If it fails          |
| 2 | Click "Expiring soon"| 3 items; yogurt red (tomorrow)    | 40  | FR-07     | Say the number, skip |
| 3 | Scan the barcode card| "Cannellini Beans, 15 oz" < 2 s   | 60  | FR-04     | Click "Add from cache" |

“Maybe” and “if it works” are how a seven-minute demo becomes eleven. The expected result is what lets you notice a wrong result instead of narrating past it; the seconds budget is what tells you at step 3 whether you are already behind.

Then close the script, wait an hour, reopen it, and execute it exactly as written — no improvising, no shortcuts, timer running.

Produce: the completed script plus your actual elapsed time written at the bottom. Reflect: Which step took longer than budgeted, and why? Nine times out of ten it is the one where you typed something. Fix it with seeded data, then re-run.

Rep 7 — Record the fallback and prove it works offline

Record the full demo path — screen and voice — with your operating system’s built-in recorder or a free, open-source tool such as OBS Studio (https://obsproject.com/). Trim it to the demo’s time budget. Then:

  1. Note the timestamp of each demo step and write those timestamps into the failure column of the script.
  2. Turn the wifi off and play the recording end to end. If it will not play, it is not a fallback.
  3. Store it at docs/presentation/demo-fallback.mp4, or put a link in the demo script if the file is too large to commit.

Produce: the recording, the timestamps in the script, and a note saying you played it offline. Reflect: Watch your own recording once, all the way through, without stopping. What did you say that you did not mean to say? Write the two worst filler phrases down; you will hear yourself reach for them next week.

Block three: honesty and questions

Rep 8 — The “what did not get done” slide

Build the three-column slide: what did not get done, why (a reason that is not “time”), and what it would cost to finish, in hours.

| Not done                | Why                                          | Cost to finish            |
|-------------------------|----------------------------------------------|---------------------------|
| FR-15 shared households | Needed the auth model deferred in ADR-0004   | ~25 h (model + 3 screens) |
| FR-18 nutrition data    | Source's terms did not permit redistribution | blocked — needs new data  |
| NFR-06 offline mode     | Descoped in Week 8 change control (CR-003)   | ~15 h; changes sync design |

Three rows maximum. Requirement IDs required.

Produce: the slide, plus the same table in docs/presentation/not-done.md. Reflect: Read your three “why” cells. Any that reduce to “I ran out of time” are unfinished — time is the symptom. Rewrite them to name the cause: an underestimate, a dependency, a decision you made in Week 8, an external constraint.

Rep 9 — Ten hostile questions

Give an assistant your requirements spec, your architecture document, and your README, then prompt: “You are a skeptical capstone committee of three senior engineers. Ask the fifteen hardest questions about this project. For each, name the artifact in this repository that would answer it.”

Keep the best ten. If the assistant misses any of these, add them yourself — every one of them shows up in real capstone rooms:

  1. Who is this for, and did you talk to any of them?
  2. What was the hardest technical problem, and how did it end?
  3. Why this stack? What would you pick if you started today?
  4. What happens when your third-party dependency is down or rate-limits you?
  5. How do you know it works? Show me a test that fails if I break something.
  6. What is the worst code in the repository, and why is it still there?
  7. What did you cut, and how did you decide?
  8. How much of this did an AI write, and what did you verify?
  9. Where do the secrets live, and what is your privacy exposure?
  10. If I hired someone Monday to take this over, what do they hit first?

Write a one-sentence answer to each. Then mark the three you cannot answer.

Question 6 is not a trap — it is the reliable senior-versus-junior detector. Compare:

BAD:  "I don't think there's really any bad code in it."

GOOD: "The import pipeline in src/import/. I wrote it in Week 10 before I understood the
       data, it has a 90-line function doing three jobs, four tests cover it so a refactor
       is safe, and it is item three in the handoff guide. It stayed because refactoring
       was 8 hours and fixing DEF-041 was 2."

Produce: docs/presentation/qa-prep.md — ten questions, ten one-sentence answers, three marked. Reflect: For each of the three you could not answer, decide right now which response you will use next week: (a) I can answer it after two hours of work this week, (b) I will say “I don’t know” plus how I would find out, or (c) it is genuinely out of scope and I can say what I scoped instead. Write the choice next to each. Choosing now is the entire point — you will not choose well on stage.

Rep 10 — Three timed rehearsals, measured

Rehearse the whole talk out loud, on a timer, three times. Between passes, cut — do not talk faster. Log every pass to a CSV with the columns pass,section,planned_min,actual_min,note, then analyze it:

python3 pace.py my-rehearsal-log.csv

(Run python3 pace.py with no arguments first to see the report format against the built-in sample log in code/pace.py.)

Produce: docs/presentation/rehearsal-log.csv with all three passes, plus the pace report pasted into docs/presentation/rehearsal-notes.md. Reflect: Which section overran in all three passes? That is your structural problem, not a delivery problem — it needs less content, not more practice. What are you cutting from it, in words?

Done? One Last Thing.

The dress rehearsal, in front of a human.

Everything above is preparation. This is the rep that actually predicts next week.

  1. Find one person — a classmate, a roommate, a family member. They do not need to understand your stack. They need a chair and a timer.
  2. Present in the real conditions you can get. The actual room if it is open. The actual projector, or at minimum an external display. The presenting laptop, on battery, with the charger you will actually bring.
  3. Run the full thirty minutes with no stopping. Deliver the demo live from wherever you plan to run it next week — and if it fails, execute your failure protocol instead of fixing it. That is the part you are rehearsing.
  4. Have them ask five questions from your Q&A prep, plus one of their own that you did not write. Answer each in under ninety seconds. Practice saying “I don’t know” out loud at least once; it is a sentence that gets easier only with reps.
  5. Ask them three questions afterward: What is this software for? What was the hardest part? What did not get done? If they cannot answer all three, your talk did not land — fix the slides that were supposed to carry those answers.
  6. Commit everything with the message milestone-15: presentation deck, demo script, three rehearsals logged.

If that loop runs clean — thirty minutes, live demo, five questions, and a stranger who can say what your software is for — you are ready. The case is built. Next week you just have to make it.

Up next: Milestone 15