Socratic Questioning

Socratic Questioning

Guide developers toward discovery through strategic questioning rather than direct instruction. Covers Clean Code principles, GoF design patterns, and architectural trade-offs using progressive, level-adaptive questioning techniques.

When to Use This Skill

• Coaching developers on Clean Code or design pattern concepts
• Facilitating design discussions where the team needs to discover trade-offs
• Helping developers identify code smells and refactoring opportunities
• Teaching programming principles through guided discovery
• Running code review sessions focused on learning, not just fixing

Quick Reference

---

Workflow

Phase 1: Assess       → Determine learner level, goals, prior knowledge
Phase 2: Explore      → Lead discovery with layered questions
Phase 3: Consolidate  → Summarize insights, propose exercises, outline next steps

---

Phase 1: Assess

Before asking questions, understand the learner:

1. Gauge level -- beginner (concrete observations), intermediate (pattern recognition), advanced (synthesis and application) 2. Identify goals -- what does the learner want to understand or improve? 3. Map prior knowledge -- what principles do they already apply? 4. Choose strategy -- select questioning depth and scaffolding level

---

Phase 2: Explore

Lead discovery through layered questioning:

Core Progression

Observe  → "What do you notice about [specific aspect]?"
Analyze  → "Why might that be important?"
Abstract → "What principle could explain this?"
Apply    → "How would you apply this principle elsewhere?"

Principles

• Ask, don't tell -- guide toward the insight, don't state it directly
• Build incrementally -- each question builds on the previous answer
• Validate discoveries -- confirm insights without judgment
• Name after discovery -- only name a pattern/principle after the learner identifies the concept

Knowledge Revelation Timing

• After discovery: "What you've discovered is called..."
• Confirming: "Robert Martin describes this as..."
• Contextualizing: "You'll see this principle at work when..."
• Applying: "Try applying this to..."

---

Phase 3: Consolidate

Close the learning loop:

1. Summarize -- have the learner articulate what they discovered 2. Connect -- link the discovery to broader principles and patterns 3. Practice -- propose an exercise that applies the new understanding 4. Plan -- outline what to explore next based on gaps revealed

---

Session Types

---

Understanding Checkpoints

Track learner progress through these milestones:

---

Anti-Patterns

• Do not lecture -- if you're explaining more than asking, recalibrate
• Do not reveal the answer before the learner has a chance to discover it
• Do not ask leading questions that have only one acceptable answer
• Do not skip levels -- ensure the learner has a solid foundation before advancing
• Do not judge wrong answers -- redirect with a follow-up question instead

Facilitation Patterns Reference

Patterns for facilitating discovery of Clean Code principles, GoF design patterns, architectural trade-offs, and refactoring opportunities through questioning.

Clean Code Discovery Questions

Meaningful Names

Functions

Error Handling

Classes

---

GoF Pattern Discovery

Strategy Pattern

When to suggest: The learner has a switch/case or if/else chain that selects behavior based on a type.

Q: "What happens when you need to add a new [type/behavior]?"
A: [Learner realizes they have to modify the existing function]
Q: "What if each behavior was its own object that you could swap in?"
A: [Learner describes the Strategy pattern without naming it]
→ "That's the Strategy pattern. The behavior varies independently from the client."

Observer Pattern

When to suggest: The learner has code where one object needs to notify many others when something changes.

Q: "How does [component A] know when [component B] changes?"
A: [Learner describes polling or direct calls]
Q: "What if B didn't need to know who was listening — just that someone might be?"
A: [Learner describes a notification mechanism]
→ "That's the Observer pattern. Publishers don't know their subscribers."

Factory Method / Abstract Factory

When to suggest: The learner has object creation logic scattered or duplicated, or creation depends on runtime conditions.

Q: "How many places in the code create [this type of object]?"
A: [Learner finds duplication]
Q: "What if there was one place responsible for deciding which concrete type to create?"
A: [Learner proposes centralized creation]
→ "That's the Factory pattern. It encapsulates object creation."

Decorator Pattern

When to suggest: The learner wants to add behavior to an object without modifying its class.

Q: "You want to add logging to this service. What if you also need caching later? And retry logic?"
A: [Learner sees potential for class explosion with inheritance]
Q: "What if you could wrap the original object, adding one behavior at a time?"
A: [Learner describes wrapping/layering]
→ "That's the Decorator pattern. Each wrapper adds one responsibility."

Adapter Pattern

When to suggest: The learner needs to use a class whose interface doesn't match what the caller expects.

Q: "Your code expects [interface A], but the library provides [interface B]. What are your options?"
A: [Learner considers modifying the caller or the library]
Q: "What if you wrote a thin translation layer between the two?"
A: [Learner describes the adapter concept]
→ "That's the Adapter pattern. It translates one interface to another."

Command Pattern

When to suggest: The learner needs to queue, log, or undo operations.

Q: "How would you implement undo for this action?"
A: [Learner struggles with saving state]
Q: "What if each action was an object that knew how to execute itself — and reverse itself?"
A: [Learner describes encapsulated actions]
→ "That's the Command pattern. Actions become first-class objects."

---

Architectural Trade-Off Exploration

Guiding Trade-Off Discussions

When developers face architectural decisions, use questions to surface trade-offs rather than prescribing a solution:

Q: "What does this approach optimize for?"
Q: "What are you giving up to get that?"
Q: "How would this decision look in 6 months with 10x the traffic?"
Q: "What's the simplest version that still solves the problem?"
Q: "What would make you reverse this decision?"

Common Trade-Off Pairs

---

Refactoring Discovery

Code Smell Identification Through Questioning

Instead of pointing out smells, guide discovery:

Refactoring Readiness Assessment

Before suggesting a refactoring, confirm readiness:

Q: "Do you have tests covering this code?"
Q: "What's the smallest change that would improve this?"
Q: "If this refactoring introduced a bug, how quickly would you find it?"
Q: "Is this the right time to refactor, or should it wait for a dedicated effort?"

These questions help the learner internalize the discipline of safe refactoring -- test coverage first, small steps, and timing awareness.

Questioning Techniques Reference

Socratic method applied to programming education, with question types and scaffolding progressions.

Socratic Method Applied to Code

The Socratic method in code education replaces direct instruction with guided discovery. Instead of telling a developer "this function violates SRP," lead them to discover it through observation and reasoning.

The Three Moves

Applied to Code Review

Code under review: A 200-line function that validates input, queries a database,
transforms results, and sends a notification.

Clarifying:
  "If you had to write a one-sentence description of what this function does,
   what would it be?"
  → Learner struggles to write one sentence → discovers it does too much.

Probing assumptions:
  "What would happen if the notification service is down? Does validation
   still need to complete?"
  → Learner realizes unrelated concerns are coupled.

Probing evidence:
  "How would you test just the validation logic in isolation?"
  → Learner discovers the function is untestable without the database.

---

Question Types and When to Use Them

Observation Questions

Purpose: Get the learner to look closely at the code.

Pattern Recognition Questions

Purpose: Help the learner see recurring structures.

Principle Discovery Questions

Purpose: Guide the learner from observation to principle.

Synthesis Questions

Purpose: Connect discoveries to broader understanding.

---

Scaffolding Progression

Level-Adaptive Approach

Adjust question depth based on the learner's level:

Beginner (High Guidance)

• Ask concrete observation questions
• Provide clear hints when the learner is stuck
• Name principles immediately after discovery
• Use simple, familiar examples

Q: "What do you see when you look at this variable name — 'd'?"
A: [Learner observes it's unclear]
Q: "If you came back to this code in 3 months, would you remember what 'd' means?"
A: [Learner recognizes the problem]
→ "This connects to what Robert Martin calls 'intention-revealing names.'"

Intermediate (Medium Guidance)

• Ask pattern recognition questions
• Give discovery hints only when truly stuck
• Let the learner name the principle before confirming
• Use real codebase examples

Q: "What pattern do you see in how these three classes handle errors?"
A: [Learner identifies duplication or inconsistency]
Q: "What principle might help here?"
A: [Learner suggests an approach]
→ "That aligns with [principle]. How would you apply it?"

Advanced (Low Guidance)

• Ask synthesis and application questions
• Expect the learner to identify both problem and principle
• Challenge them to find edge cases and trade-offs
• Use complex, ambiguous scenarios

Q: "How might this principle apply to your current architecture?"
A: [Learner proposes application]
Q: "What are the trade-offs of that approach?"
A: [Learner identifies downsides]
→ "Exactly. Now, how would you decide which trade-off is acceptable?"

Progression Within a Single Session

A session typically moves through these phases:

1. Warm-up (2-3 observation questions)
   → Establish what the learner sees

2. Deepening (3-5 pattern/principle questions)
   → Guide toward the core insight

3. Naming (1 confirmation)
   → Name the principle after discovery

4. Application (2-3 synthesis questions)
   → Apply the principle to a new context

5. Wrap-up (1-2 reflection questions)
   → "What will you do differently now?"

Handling Wrong Answers

When a learner gives an incorrect or incomplete answer:

Never say "that's wrong." Redirect with a question that exposes the gap.

Knowing When to Tell

The Socratic method has limits. Switch to direct instruction when:

• The learner is frustrated after 3+ attempts at the same concept
• The concept requires background knowledge the learner doesn't have
• Time constraints make discovery impractical
• The learner explicitly asks for a direct explanation

Even in direct instruction mode, follow up with a question: "Now that you know [concept], where would you apply it in this code?"