IT-Specific Pedagogy

Core Principle

Use IT-specific formats when the objective is a habit requiring muscle memory (TDD, refactoring, collaborative coding). If "watch a video" could achieve the outcome, generic activities suffice.

Format 1: Coding Kata

Definition: A small, fixed programming problem practiced repeatedly, with attention on technique (TDD cycle, refactoring, incremental design), not problem-solving. The problem is deliberately trivial so cognitive load goes entirely to the technique.

Kata Format Variants

Classic Kata Catalogue

Selection rule: FizzBuzz and String Calculator are correct entry points for TDD-naive groups. Never use Gilded Rose as a first kata — it assumes TDD fluency.

Designing a Kata for a Specific Outcome

1. Fix the problem (removes problem-solving overhead)
2. Name the technique being practiced (e.g., "This session focuses solely on the refactor step")
3. Apply one constraint that makes the anti-pattern impossible
4. Time-box sessions (20-30 min beginners; 45 min advanced)
5. Close with retrospective: "What did you notice about the technique, not the code?"

Format 2: Coding Dojo

Definition: Group practice session with single keyboard and projector, explicit facilitation rules, and retrospective. Kata is the problem; Dojo is the container.

Non-Negotiable Facilitation Rules

1. One keyboard, one projector — all code visible at all times
2. Pair at keyboard (driver + navigator) — rotate every 5-7 minutes
3. No criticism from observers — questions and suggestions only
4. Everyone codes — nobody is permanently a spectator
5. Retrospective always closes — 15-20 minutes: what did we learn?
6. Egoless programming norm — state at start: "deleting your code is good behavior"

Session Structure

Introduction (5 min)      — kata, rules, learning focus
Coding (70-90 min)        — pairs rotate every 5-7 min
Retrospective (15-20 min) — technique insight, not code review

Group Size Constraints

Above 10: each participant's keyboard time drops below 10 minutes in a 90-minute session.

Format 3: Mob / Ensemble Programming

Core rule: "For an idea to go from your head into the computer, it MUST go through someone else's hands."

Roles

Navigator rule: Speak at the highest abstraction level the driver can act on.

Rotation and Group Sizing

Large groups (8-20): Split into parallel mobs of 4-6. Same problem, different groups. Reconvene to compare solutions.

Format 4: TDD Workshop Design

Three Failure Modes to Detect and Counter

Workshop Activity Sequence

Stage 1 — Worked Example (30-45 min): Facilitator writes code live with narration. Explicitly verbalize uncertainty. Visible mistakes are essential — they model recovery behavior. Do NOT use a polished prepared demo.

Stage 2 — Completion Exercise (45-60 min): Provide a half-completed kata. Participants continue in the same style. The existing structure prevents mental-design-first patterns.

Stage 3 — Independent Kata (60-90 min): Full kata from scratch, in pairs. Facilitator circulates using the three detection questions. FizzBuzz for TDD novices; String Calculator for basic comfort.

Stage 4 — Constrained Kata (advanced only): "TDD as if you meant it" — all production code must first appear inside the test file. Makes test-last technically impossible.

Chicago vs London School

Sequencing rule: Chicago school always first. Mixing both in a beginners' session causes confusion.

Samman Learning Hour (Emily Bache)

Framing talk        (10-15 min) — context, concept, why it matters
Demonstration/kata  (15-20 min) — facilitator shows technique live
Pair kata exercise  (30-45 min) — participants practice
Retrospective       (10 min)    — what did you notice?

Format 5: Architecture Katas

Definition: Small-group exercise where teams design a system from a brief requirement, then present to and are questioned by peer groups.

Session Structure

Problem assignment     (5 min)   — each group gets a different kata
Requirement discovery  (10 min)  — interview moderator as "customer"
Design phase           (20-30 min) — sketch components, integrations, quality attributes
Presentation + Q&A     (10 min/group) — present; other groups challenge
Peer voting            (5 min)   — groups vote; moderator facilitates discussion

Peer review teaches that architecture is a communication artifact. Voting de-centers the facilitator.

Format 6: Refactoring Katas and Code Smell Workshops

Non-negotiable sequencing rule: Characterization testing must precede refactoring in any legacy code workshop.

Code Smell Scavenger Hunt — Steps

1. Brief slide per smell: what it is, signals, targeted refactoring
2. Teams search assigned sections (15 min)
3. Post-it results; dot-vote most impactful example
4. Mob-refactor the top vote (20-30 min)
5. Retrospective: "Does this appear elsewhere in our codebase?"

Format 7: Live Coding vs Prepared Demo

Participatory live coding produces superior outcomes vs polished demos for skill acquisition. The instructor making visible mistakes is a feature — it models recovery behavior.

Five highest-priority tips (Carpentries):

1. Go slowly — narrate every step; give participants time to catch up
2. Mirror learner environment — same IDE, font size, terminal
3. Stick to prepared material — avoid improvisation
4. Embrace mistakes openly — demonstrate diagnosis and recovery
5. Real-time feedback — sticky notes (green = OK, red = help)

Format 8: Code Retreat

Definition: Full-day practice event. 5-6 sessions of 45 minutes, always Conway's Game of Life. Code deleted after every session. Pairs rotate. Different constraints each session.

When to use: When participants need multiple valid design approaches and delivery pressure must be completely removed. Assumes TDD baseline — not appropriate for beginners.

Code deletion rule: Eliminates ego investment and delivery pressure.

Format Selection Quick-Reference

Contra-Indicators:

• Mob programming: Group > 7, hostile dynamics, one expert dominating navigator role
• Code Retreat: TDD novices without baseline red-green-refactor; sessions < full day
• Katas: No IDE setup; non-negotiable delivery pressure
• Randori: Group > 10; no working shared screen/projector