Lesson 1 of 4 · 60 min
A workshop is a sequence of learner decisions
Create a time-boxed workshop plan with a core path and recovery branch.
A workshop is not a long demo with pauses for copying. The learner should make decisions, inspect output, and correct a failure. Plan the session around those actions. Each segment needs a starting state, an expected result, and a way for a learner who is behind to rejoin without losing the central concept.
Choose one core outcome that fits the available time. Optional extensions can serve faster learners, but they should not become prerequisites for later core steps. A workshop that requires everyone to finish an optional integration before the final exercise turns variation in experience into exclusion. Provide a known-good checkpoint at each major boundary.
Budget time for setup and failure. A thirty-minute technical exercise can consume an hour if every participant must create an account and troubleshoot network access. A local fixture can remove that dependency when the learning goal concerns the mechanism. If a live service is central to the goal, verify access requirements in advance and provide a clearly labelled fallback.
The fallback must preserve honesty. A recorded output can explain what would happen, but it is not a live successful request. A simulated provider can teach a client contract while leaving real authentication unverified. Tell learners which mode is running. This avoids teaching them to confuse a presentation recovery technique with product reliability evidence.
Worked example
A fictional forty-five-minute workshop teaches duplicate-event handling. The plan allocates five minutes to the problem and prediction, eight to local setup, ten to the first fixture, ten to a failure variation, seven to a transfer exercise, and five to review. The core fixture uses E1 twice and E2 once. The failure variation changes the repeated E1 payload to expose conflict handling.
At minute thirteen, a learner without a working runtime can use the printed trace table and still complete the prediction and transfer tasks. A faster learner adds durable storage as an optional extension but is not required to deploy a service. The final review asks everyone to explain why event amount is not a safe identity key.
Define the core checkpoint states
A rejoin point is useful only if the learner can identify its state and continue. A folder labelled solution is not enough when the next exercise assumes a particular input, output, and version. State the checkpoint contract explicitly.
| Checkpoint | Required learner state | Verification | Rejoin material |
|---|---|---|---|
| Before execution | Understands fixture IDs and amounts | Predicts total for repeated ID | Printed input table |
| After first run | Has output 15 and can trace seen | Explains why E1 counts once | Known-good code and state trace |
| After conflict variation | Recognizes repeated ID with changed payload | Predicts rejection under conflict-aware policy | Completed conflict trace |
| Transfer | Chooses identity for a business effect | Explains two new purchases plus repeated delivery | Fresh case without copied answer |
The optional durable-storage extension must not change the later core fixture. Otherwise learners who stayed on the local path cannot join the final discussion. Give advanced learners a separate question about what a local set cannot guarantee, then bring them back to the same transfer boundary.
Budget by learner action
The forty-five-minute plan already uses all available time:5+8+10+10+7+5=45. Additional setup trouble cannot be absorbed without changing something. Decide in advance which optional explanation can shorten and which core assessment must remain.
A facilitator can use an explicit minute-thirteen decision: if a learner cannot run locally, offer the trace path and a later setup clinic. That preserves participation without claiming execution succeeded. Learners who need to demonstrate actual installation must still complete a separate run after the workshop; the trace path does not satisfy that outcome.
Design instructions for transitions, not just activities. Say what output should be visible, what files or state to keep, and what the next step assumes. Silent jumps between presenter checkpoints can leave learners behind even when each command is correct.
Prepare a fallback contract
code
1Fallback mode: printed or local recorded trace2Demonstrates: event identity decisions and expected state transitions3Does not demonstrate: participant environment setup or live API access4Switch trigger: one bounded diagnostic attempt exceeds planned time5Rejoin point: same fixture and prediction exercise as live path6Follow-up: publish corrected setup guidance and exact unresolved symptomA recording can show expected behavior but cannot become evidence of current service availability. A simulated provider can support request/response reasoning while authentication remains untested. Say which mode is running before explaining its result. Learners should not have to infer whether they saw a live execution.
Facilitate without removing the thinking
When someone is stuck, first identify whether the issue is setup, task interpretation, or the mechanism itself. Giving the final answer to a conceptual question can remove the evidence you need about their model. Offer a smaller prompt: which identifier was already in seen, or which state survived the restart?
Use a hint sequence that reveals one step at a time. For example, first ask learners to underline repeated IDs. Then ask them to mark the state after the first event. Only then show the completed trace. This lets the learner do useful reasoning even when syntax is unfamiliar.
Do not use speed as the only signal of understanding. A fast participant can copy without a correct model; a slower participant can reason accurately while navigating an unfamiliar environment. The transfer explanation provides a more relevant check.
Misconceptions and a second exercise
One misconception is that finishing every slide is equivalent to finishing the workshop. Slides are a teaching input, not the learner outcome. Another is that an honest fallback weakens the session. A labelled fallback can preserve reasoning while clearly separating the missing execution evidence.
Exercise: at minute 23, the group has completed the first fixture but not conflict or transfer. Design a twenty-two-minute remainder. One answer uses eight minutes for conflict prediction/trace, seven for transfer, five for review, and two for next steps, cutting the optional extension entirely. Award one point for the time sum, one for preserving contrast, one for transfer, and one for stating what remains uncompleted. Alternative allocations can pass if they preserve the declared learning outcome.
A workshop plan should include this branch before the session. That reduces pressure to improvise misleading claims when time is short. The finished artifact is a sequence of learner decisions with verified rejoin points, not merely a presenter timetable.
Exercise and solution
The runtime installation takes fifteen extra minutes for half the room. Revise the remaining plan. Move those learners to the trace-based core, shorten optional extension time, and preserve the transfer exercise. Award one point for retaining the learning outcome, one for a usable rejoin path, and one for explicitly labelling the fallback. Removing all learner practice to finish the slides fails the purpose.
Interview probe and wrap-up
How do you handle a live demo failure on stage? A strong answer names the symptom, spends a bounded time on one diagnostic check, switches to a labelled fallback, and continues teaching the mechanism. Follow up with how to repair the published materials afterward. A weak answer hides the failure or blames the audience. The session succeeds when learners can complete and explain the core action, even when the presentation needs to adapt.
Sources
docsGoogle technical writing: audience and documentsdevelopers.google.comdocsGoogle code-sample style guidancedevelopers.google.comdocsGitLab Developer Advocate rolehandbook.gitlab.comCheckpoint
A 45-minute workshop uses all 45 minutes. Setup now needs ten more minutes. The session must still end on time. What is the sound revision?
AMove the final transfer exercise to unobserved homework but keep reporting the original in-session outcome.BKeep every activity and assume the ten minutes can be recovered by speaking faster.CCut or shorten noncore work, preserve the declared core check, and show the revised timings.DHave late learners watch the final demonstration and count that as completion of the hands-on outcome.
Sign up free to answer and see whyCheckpoint
What makes a rejoin checkpoint usable?
AInput/state, expected result, and the next step's assumptions.BOnly the presenter's current branch name.CA folder named solution with no state description.DA screenshot alone.
Sign up free to answer and see whyCheckpoint
A trace fallback replaces failed installation. What remains unverified?
AThe identity reasoning that the learner explained.BThe printed fixture's arithmetic if correctly traced.CThe supplied expected state sequence.DThe learner's actual environment execution and live access.
Sign up free to answer and see whyCheckpoint
An optional extension changes state required by the final core exercise. Main problem?
AIt makes the extension's completion evidence sufficient for every learner.BIt makes optional work a hidden prerequisite for rejoining.CIt verifies the same core state without needing a rejoin artifact.DIt guarantees the core fixture remains equivalent after the extension.
Sign up free to answer and see whyCheckpoint
A learner's trace treats two different event IDs with equal amounts as one event. Which first hint best diagnoses the misconception?
AShow the final total and ask the learner to change their answer to match.BRepeat the installation steps to restore the original fixture.CAsk which identifier the seen set contains, then trace the second ID before revealing the total.DGive the complete corrected implementation before asking for a prediction.
Sign up free to answer and see whyCan you keep the core learning outcome intact when setup fails, while stating which execution evidence the fallback does not provide? State the relevant identifiers, failure boundary, and evidence in your own words before selecting your confidence.
Not yetGetting thereConfident
Sources
Free to read · better with Enzo
Learn it with Enzo
Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.