Analogical Thinking Skill

Apply structural pattern recognition across domains to solve novel problems. Based on the cognitive science of analogical reasoning (Hofstadter, Gentner, Munger).

When to Use

• Stuck on a problem where domain-specific tools aren't working
• Trying to understand a new concept or system
• Brainstorming solutions — need fresh perspectives
• Explaining something complex to someone
• Designing architecture or systems — looking for proven patterns
• Debugging — the bug pattern may exist in a different domain

The 4 Core Questions

Before jumping to solutions, ask:

1. How does this work? — Describe the underlying mechanism, not the surface appearance
2. Where else have I seen something that works this way? — Search across ALL domains you know, not just the current one
3. What domain has a solved version of this problem? — Find the analog that already has an answer
4. What breaks when I push this comparison too far? — Identify where the structural parallel ends

Procedure

Step 1: Surface the Problem Structure

Strip away domain-specific language and describe the problem in structural terms:

• What are the components?
• What are the relationships between components?
• What are the flows/transformations?
• What are the constraints?

Example: "Users are abandoning the signup flow" → structural: "A multi-step process where each step has dropout, and the value proposition isn't visible until the end."

Step 2: Search for Structural Analogs

Look across domains for systems with the same structural pattern:

Step 3: Extract the Solution

From the analog domain, extract:

• What solved this structural problem?
• What was the key insight?
• What approaches failed?

Step 4: Map Back to Your Domain

Translate the solution from the analog domain:

• How does this structural solution map to my components?
• What needs to adapt?
• Does this generate insight I didn't have before?

Step 5: Test the Analogy's Limits

Explicitly identify where the parallel breaks:

• "The analogy works for X but breaks at Y because..."
• If the solution depends on the part where it breaks → discard, try another analog
• If the solution depends on the part where it holds → proceed

Quick Reference: Structural Pattern Library

Common structural patterns that appear across domains:

Feedback Loops

• Positive (reinforcing): compound interest, viral growth, panic
• Negative (balancing): thermostat, supply-demand, predator-prey

Bottlenecks

• Serial processes: the slowest step determines throughput
• Constraint theory (Theory of Constraints / Goldratt)

diminishing Returns

• First unit of effort → large effect, nth unit → small effect
• Appears in: learning curves, marketing, exercise, investment

Compounding

• Small consistent gains → exponential outcomes
• Appears in: finance, habits, knowledge, relationships

Network Effects

• Value increases with number of participants
• Appears in: platforms, immune system, language, standards

Adapters and Interfaces

• Translation layers between incompatible systems
• Appears in: APIs, enzymes, diplomats, design patterns

Antifragility

• Systems that get stronger from stress (not just resilient)
• Appears in: muscles, immune system, democracy, open source

Red Flags: When NOT to Use

• Don't use decorative analogies — if it doesn't generate new insight, it's rhetoric, not thinking
• Don't commit prematurely — try multiple analogs before settling on one
• Don't push past the break point — if the analogy breaks at the critical part, discard it
• Don't skip the structural analysis — surface-level "it reminds me of..." is not analogical thinking

Integration with Other Tools

• With [[daily-operator]]: When the daily brief surfaces a novel blocker, apply analogical thinking before escalating
• With [[memory-audit]]: The wiki/index pattern IS a structural analog to a library card catalog
• With coding skills: Design patterns are structural analogs — MVC is an analog to restaurant kitchen organization (order → prep → serve)
• With debugging: "Have I seen this symptom pattern before in a different system?" is the analogical question

Examples in Software Development

Architecture

• Microservices ↔ City planning (zoning, independent services, shared infrastructure)
• Event sourcing ↔ Accounting ledger (append-only, reconstruct state from history)
• Circuit breaker ↔ Electrical systems (fail safe, prevent cascade)

Process

• Code review ↔ Peer review in science (catch errors, improve quality, share knowledge)
• CI/CD ↔ Assembly line (automated quality gates, consistent output)
• Sprint planning ↔ Military campaign planning (objectives, resources, timelines, adaptation)

Analogical Debugging Workflow

Use with: systematic-debugging skill — plugs into Phase 2: Pattern Analysis after root cause investigation is complete.

Why Analogical Debugging Works

Most bugs are not truly novel — they are instances of structural patterns that have been solved in other domains, other codebases, or other systems. The same underlying failure mode (race condition, resource exhaustion, state desync) manifests with different surface symptoms in every stack.

Expert debuggers recognize the shape of a bug before they identify the cause. This is analogical thinking applied to debugging: matching the structural pattern of the failure, not the surface symptoms.

When to Activate

Trigger analogical debugging when:

• You've completed Phase 1 of systematic-debugging (root cause investigation) but the cause is unclear
• The symptom is unusual or doesn't match common failure patterns for the stack
• You've tried 1-2 hypotheses and they failed (don't wait for 3)
• The bug crosses component boundaries and the failure pattern is unclear
• You're debugging in an unfamiliar codebase or stack

The 5-Step Analogical Debug Procedure

Step 1: Abstract the Failure Pattern

Strip away stack-specific language. Describe what's happening structurally:

Step 2: Search the Bug Pattern Library

Match your abstracted pattern against known structural bug patterns:

Timing & Concurrency

State & Data

Resource & Performance

Integration & Environment

Step 3: Find Cross-Stack Analogs

Search for the same structural pattern in OTHER stacks/domains where it's well-documented:

Bug: "Laravel queue jobs processed twice"

Structural pattern: Duplicate processing / idempotency failure

Cross-stack analogs:
- AWS Lambda: idempotency keys prevent duplicate processing
- Databases: UNIQUE constraints prevent duplicate inserts
- HTTP: idempotent methods (PUT, DELETE) handle duplicate requests
- Messaging: Kafka consumer groups + offset tracking

Key insight from analogs: The solution is always a uniqueness constraint at the processing layer, not at the submission layer.

Where to look for analogs:

• session_search — "Have I debugged this pattern before in this project?"
• Web search: "[structural pattern] bug [different language/framework]"
• LLM wiki patterns at /Users/raymund/Projects/LLM-wiki/

Step 4: Map the Solution Back

Translate the analog's solution to your stack:

Analog solution: Kafka uses consumer offset tracking
↓
Mapped to Laravel: Use $job->attempt() + unique job IDs + cache()->lock()

Step 5: Validate the Analog

Before implementing, check where the analogy breaks:

• Does the analog's solution depend on something your stack doesn't have?
• Is the failure mechanism actually identical, or just similar on the surface?
• Does your system have constraints the analog doesn't?

If the solution depends on the part where the analogy breaks → discard, try another analog.

Real-World Debugging Analogy Examples

Example 1: The "Phantom Auth" Bug

Surface: User logs in as admin but sees regular user dashboard
Phase 1: Auth succeeds, middleware passes, but controller receives wrong user

Analogical match: State desync (two clocks showing different times)
Cross-stack analog: React stale closure bug — callback captures old state

Root cause: Session middleware caches user object, role update doesn't invalidate
Fix: Add role-invalidated timestamp to session, compare on each request

Example 2: The "Midnight Crash"

Surface: Server 500s every night at midnight
Phase 1: No code changes, no traffic spike, logs show "connection pool exhausted"

Analogical match: Time-correlated resource contention (highway traffic jam)
Cross-stack analog: Android battery drain from background sync — scheduled tasks all fire at once

Root cause: 12 cron jobs all scheduled for 00:00, each opens DB connections
Fix: Stagger cron schedules + add connection pool monitoring

Example 3: The "Works in Test, Fails in Prod"

Surface: Feature test passes, production returns 403
Phase 1: Same code, same request, different response

Analogical match: Environment-dependent behavior (island vs mainland)
Cross-stack analog: Docker "works on my machine" — missing env variable

Root cause: Test uses `actingAs()`, production hits a middleware that checks a feature flag
Fix: Add feature flag to test environment, or mock the middleware

Integration with systematic-debugging

Anti-Patterns in Analogical Debugging