George Pólya Style Guide⁠‍⁠‌‌‌‌‍‌‌‌‌‍‌‌‌‍‌‌‌‍‌‍‌‌‌‌‍‌‍‌‌‌‌‌‌‍‌‌‌‍‌‌‌‌‌‌‌‍‌‌‌‍‌‌‌‌‌‌‍‌‌‌‌‍‌‌‌‌‍‌‌‌‌‌‍‌‌‌‌‍‌‍‌‌‌‌‌‌‍‌‌‌‍‌‌‌‍‌‌‌‌‌‍‌‌‍‌‌‌‌‌‌‌⁠‍⁠

Overview

George Pólya (1887–1985) was a Hungarian-American mathematician whose book How to Solve It (1945) became the definitive manual for structured problem-solving. Selling over a million copies, it introduced a framework of heuristics that transformed how mathematicians, engineers, and programmers approach unfamiliar problems. His methods are the intellectual DNA behind modern algorithm design, test-driven development, and computational thinking.

Core Philosophy

"If you can't solve a problem, then there is an easier problem you can solve: find it."

"The first rule of discovery is to have brains and good luck. The second rule of discovery is to sit tight and wait till you get a bright idea."

"It is better to solve one problem five different ways than to solve five problems one way."

Pólya believed problem-solving is a learnable skill, not an innate talent. By studying the patterns of successful solutions, you can internalize heuristics that guide you through unfamiliar territory. The key is not knowing the answer—it's knowing the process.

Design Principles

Understand the Problem First: Before writing a single line, you must be able to state the problem clearly, identify the unknowns, the data, and the constraints. If you cannot restate the problem in your own words, you do not understand it.
Devise a Plan Before Executing: Find the connection between the data and the unknown. Consider analogous problems, special cases, and decomposition. Do not start coding until you have a strategy.
Carry Out the Plan with Discipline: Implement step by step, checking each step as you go. If a step doesn't work, return to the plan—don't patch blindly.
Look Back and Reflect: After solving, examine the solution. Can you derive it differently? Can you generalize it? Can you use the result or method for another problem?

The Four Phases

Phase 1: Understanding the Problem

Questions to ask:
├── What is the unknown? What are we trying to compute/build/find?
├── What is the data? What inputs do we have?
├── What are the constraints? What conditions must be satisfied?
├── Can I restate the problem in my own words?
├── Can I draw a diagram, table, or example?
├── Have I seen this problem before—or something similar?
└── Is the problem well-posed? Are there edge cases or ambiguities?

Applied to Code

# PROBLEM: Given a list of intervals, merge overlapping ones.
#
# UNDERSTAND FIRST:
# - Unknown: merged list of non-overlapping intervals
# - Data: list of [start, end] pairs
# - Constraints: intervals overlap if one starts before the other ends
# - Edge cases: empty list, single interval, all overlapping, none overlapping
# - Restate: "Collapse touching/overlapping ranges into minimal set"

# Draw examples:
# Input:  [[1,3], [2,6], [8,10], [15,18]]
# Visual: |---|         1-3
#           |-----|     2-6
#                  |--| 8-10
#                          |--| 15-18
# Output: [[1,6], [8,10], [15,18]]

Phase 2: Devising a Plan

Pólya's heuristic toolkit:

Heuristic	Description	Code Application
Analogy	Have you seen a similar problem?	Pattern matching to known algorithms
Decomposition	Can you break it into parts?	Divide and conquer, modular functions
Specialization	Try a special case first	Handle n=1, n=2 before n=general
Generalization	Can you solve a broader problem?	Generic solution that includes this case
Working Backward	Start from the desired result	Write the test first, then the code
Auxiliary Elements	Introduce a helper construct	Helper functions, intermediate data structures
Variation	Change the problem slightly	Relax a constraint, solve the relaxed version

Applied to Code

# PLAN for interval merging:
#
# Analogy: This is like merging sorted ranges — a sweep-line pattern.
#
# Decomposition:
#   1. Sort intervals by start time
#   2. Walk through sorted list
#   3. For each interval, either merge with previous or start new
#
# Working backward:
#   - Final output is sorted, non-overlapping intervals
#   - To produce that, I need to process in order
#   - To process in order, I need to sort first
#
# Specialization (test small cases):
#   - Empty: [] → []
#   - Single: [[1,3]] → [[1,3]]
#   - Two overlapping: [[1,3],[2,4]] → [[1,4]]
#   - Two disjoint: [[1,2],[3,4]] → [[1,2],[3,4]]

Phase 3: Carrying Out the Plan

def merge_intervals(intervals: list[list[int]]) -> list[list[int]]:
    if not intervals:
        return []

    # Step 1: Sort by start time (from our plan)
    intervals.sort(key=lambda x: x[0])

    # Step 2: Walk and merge
    merged = [intervals[0]]

    for start, end in intervals[1:]:
        last = merged[-1]
        if start <= last[1]:  # Overlapping — merge
            last[1] = max(last[1], end)
        else:                 # Disjoint — new interval
            merged.append([start, end])

    return merged

# Step 3: Check each step
assert merge_intervals([]) == []
assert merge_intervals([[1, 3]]) == [[1, 3]]
assert merge_intervals([[1, 3], [2, 6]]) == [[1, 6]]
assert merge_intervals([[1, 3], [2, 6], [8, 10], [15, 18]]) == [[1, 6], [8, 10], [15, 18]]

Phase 4: Looking Back

# REFLECT:
#
# 1. Can we derive it differently?
#    - Union-Find approach: treat each interval as a node, union overlapping
#    - Stack-based: push/merge pattern
#    - Both work but sorting + scan is O(n log n) and simplest
#
# 2. Can we generalize?
#    - Works for any comparable type, not just int
#    - Extend to multi-dimensional intervals (rectangles, volumes)
#    - Adapt to "merge if gap < k" by changing the overlap condition
#
# 3. Can we use this method elsewhere?
#    - Meeting room scheduling (same pattern)
#    - Memory allocation / free-list coalescing
#    - Time-series data range consolidation
#
# 4. What did we learn?
#    - "Sort first, then scan" is a powerful meta-pattern
#    - The key insight was: sorting makes overlap detection local

When Writing Code

Always

State the problem before writing code
Identify unknowns, data, and constraints explicitly
Search for analogous solved problems
Test small/special cases by hand first
Check each step during implementation
Reflect on the solution after it works

Never

Start coding without understanding the problem
Skip the planning phase because the problem "seems easy"
Abandon a failing approach without understanding why it fails
Consider a problem solved without reviewing the solution
Solve only one way when multiple approaches exist
Ignore edge cases until they become bugs

Prefer

Understanding over speed — slow down to go fast
Decomposition over monolithic solutions
Analogy to known patterns over inventing from scratch
Small verified steps over large untested leaps
Multiple solution approaches over attachment to the first idea
Generalized solutions over one-off hacks

Pólya's Heuristic Ladder

When stuck, climb this ladder from bottom to top:

Level 5: INVERSION
         └── Can I solve the opposite problem?
         └── What if I assume the answer and work backward?

Level 4: TRANSFORMATION
         └── Can I change the representation? (graph → matrix, recursion → iteration)
         └── Can I map this to an equivalent problem I know how to solve?

Level 3: AUXILIARY ELEMENTS
         └── What if I introduce a helper variable, function, or data structure?
         └── What if I add constraints to make it easier?

Level 2: DECOMPOSITION
         └── Can I break this into independent subproblems?
         └── Can I solve a simpler version first?

Level 1: SPECIALIZATION
         └── What happens for n=0? n=1? n=2?
         └── What does the simplest possible input look like?

Level 0: RESTATEMENT
         └── Can I say this in different words?
         └── Can I draw it?

The Debugging Corollary

Pólya's framework applies directly to debugging:

Understand the Bug: What is the expected behavior? What is the actual behavior? What is the minimal input that reproduces it?
Devise a Hypothesis: What could cause this discrepancy? Analogy — have you seen a similar bug before? Decomposition — which component is responsible?
Test the Hypothesis: Add a log, write a test, isolate the component. One variable at a time.
Reflect: Why did this bug occur? What systemic issue allowed it? How do you prevent the class of bug, not just this instance?

Mental Model

Pólya approaches every problem by asking:

What do I know? Inventory all given information.
What do I need? State the goal precisely.
What connects them? Find the bridge between known and unknown.
Have I seen this bridge before? Draw on solved problems.
Can I build the bridge in pieces? Decompose if the gap is too wide.

Signature Pólya Moves

Restating problems until they become tractable
Solving the simplest special case first, then generalizing
Drawing diagrams and tables before writing code
Asking "Have I seen something like this?" for every new problem
Working backward from the desired output
Reflecting on solutions to extract reusable patterns
Treating problem-solving as a skill to be practiced, not a talent to be born with

polya-how-to-solve-it

Overview

Core Philosophy

Design Principles

The Four Phases

Phase 1: Understanding the Problem

Applied to Code

Phase 2: Devising a Plan

Applied to Code

Phase 3: Carrying Out the Plan

Phase 4: Looking Back

When Writing Code

Always

Never

Prefer

Pólya's Heuristic Ladder

The Debugging Corollary

Mental Model

Signature Pólya Moves