Skip to main content

Devising a Plan Converts Random Attempts into Experiment

What This Concept Is​

Devising a plan is the deliberate act of choosing an attack before executing arithmetic, code, or proof steps.

A plan is not the solution. It is a short, testable route from the given to the unknown. A useful plan typically answers four questions in a single paragraph:

  • which related problem do I already know how to solve? (analogy)
  • which heuristic or strategy is the problem inviting? (working backwards, invariant, induction, reduction, simulation, divide-and-conquer, contradiction, pigeonhole...)
  • what intermediate quantity, lemma, or transformation do I need? (the sub-goal)
  • what does success look like at each step? (the stopping criterion)

Plans are falsifiable: they commit to a prediction that execution can refute. Random attempts are not falsifiable because they never predicted anything. That distinction -- committing to a prediction -- is what converts problem solving from luck into engineering.

Devising a plan sits after phase one (understanding) and before phase three (carrying out). It is the thinnest of the four Polya phases because a good plan is short: one paragraph, often five sentences. A plan that fills a page is usually a half-executed solution dressed up as planning, and it carries all the risks of executing before you have chosen.

The plan also declares a budget. "I will try pigeonhole for 20 minutes; if it does not produce a clean split by then, the hypothesis is probably wrong and I switch to contradiction." Budgeted plans let you detect stuck-ness quickly. Unbudgeted plans turn into thrashing.

Why It Matters Here​

Most "I tried random things" failures are plan failures. Writing code, running calculations, or manipulating formulas without a plan burns time and hides the real obstacle: you cannot diagnose what went wrong because there was no hypothesis to refute.

Planning transforms problem solving from luck into engineering: you form a hypothesis, run an experiment, interpret the result, and update. The plan is the hypothesis. Execution is the experiment. Looking back is the interpretation. This is the scientific method adapted to a sheet of paper.

Forward pipeline: Semester 2 (algorithm design) is a catalogue of plans -- divide-and-conquer, greedy, DP, flow, reduction -- and it expects you to name the plan before you code. Semester 5 (protocol design) requires a plan paragraph per design decision. Semester 7 (architecture decisions) encodes the plan as the "Decision" and "Consequences" of an ADR. Every engineering review you will sit through later is a peer-inspected plan.

Concrete Examples​

Example 1 -- Ramsey $R(3,3) = 6$​

Problem: Prove that among any six people, there are either three mutual friends or three mutual strangers.

  • Related problem? The classic Ramsey theorem $R(3,3) = 6$.
  • Heuristic? Pigeonhole on edges incident to one chosen vertex.
  • Intermediate quantity? Pick one person $P$. Among the other five, the five edges from $P$ are each "friend" or "stranger", so by pigeonhole $\lceil 5/2 \rceil = 3$ share the same label.
  • Success check? Let ${A, B, C}$ be three people all with the same relationship $r$ to $P$. If any edge among $A, B, C$ is of type $r$, that pair plus $P$ is a monochromatic triangle. Otherwise all three edges among ${A, B, C}$ are of the opposite type -- a monochromatic triangle among ${A, B, C}$.

This plan fits in one paragraph and fully determines the proof. The write-up follows mechanically.

Example 2 -- fast exponentiation plan​

Problem: Compute $a^n \bmod m$ for $n$ up to $10^{18}$.

  • Related problem? Repeated squaring; the recurrence $a^n = (a^{n/2})^2$ if $n$ is even, $a \cdot a^{n-1}$ if $n$ is odd.
  • Heuristic? Divide-and-conquer on the exponent; reduce modulo $m$ after every multiplication to keep numbers bounded.
  • Intermediate quantity? A loop invariant: at the start of iteration $i$, the accumulator equals $a^{k}$ where $k$ is the prefix of $n$'s binary expansion already consumed.
  • Success check? Loop terminates in $O(\log n)$ steps because $n$ halves; each step uses one modular multiplication. Final invariant gives the answer.

The plan is five sentences. The code is ten lines. Without the plan, the code is forty lines of special cases.

Common Confusion / Misconceptions​

Plan-as-solution. Learners sometimes conflate a plan with a solution. A plan is a strategy sketch; it should be short enough to fit in a comment block. If it is longer than a paragraph, you have started executing.

Absence disguised as humility. Treating "I have no idea" as absence of plan. Even "try small cases and look for a pattern" is a valid plan. The absence of a plan is random keystrokes, not humble-sounding strategy.

Retroactive planning. Writing the plan after the solution. A retroactive plan is reflection, not planning. The point of planning is to make the next step of execution a directed experiment.

Single-plan-commitment. Committing to the first plan that comes to mind and refusing to budget for switching. A good planner names a second plan on the same page so that the budgeted switch is not emotional.

How To Use It​

Run this micro-protocol before executing:

  1. Write one sentence: "My plan is to ...".
  2. Name the related problem, or write "none; exploratory".
  3. Name the heuristic (invariant, contradiction, induction, reduction, simulation, divide-and-conquer, ...).
  4. Write the first subgoal, not the solution.
  5. Write how you will know the subgoal is achieved.
  6. Write the time budget (e.g. "30 minutes, then re-plan").
  7. Name the fallback plan in one line.

If you cannot complete steps 1-5 in five minutes, your understanding phase is incomplete. Go back to phase one.

Transfer / Where This Shows Up Later​

  • Semester 2 (algorithm design paradigms). Every paradigm -- greedy, D&C, DP, network flow -- is a named plan. Recognising which one to commit to is phase two.
  • Semester 2 (DP recurrences). Before writing a recurrence, you declare the state and the transition in English -- the plan before the code.
  • Semester 3 (design patterns). "Use the Observer pattern" is a plan sketch; "here's the class diagram" is the solution.
  • Semester 4 (debugging). Before changing code, state your hypothesis in one line and what evidence would refute it. Without the hypothesis, you are guessing.
  • Semester 5 (protocol design). An RFC is a multi-page plan. The "Motivation" and "Design" sections are phase two scaled up.
  • Semester 7 (ADRs). The "Decision" section is literally a plan paragraph.
  • Semester 10 (capstone). Weekly plans survive when they are hypothesis-shaped: "if we do X, then Y will happen; if Y does not happen, we switch to Z."

Check Yourself​

  1. What is the difference between a plan and a solution? Give a problem where you can plan in one sentence but the solution takes a page.
  2. Why is "try things and see what happens" not a plan? What is the missing ingredient that would make it one?
  3. For Dijkstra's shortest-path algorithm, what is the one-sentence plan? What is the one-sentence fallback plan if the graph has negative edges?
  4. Why does a plan need a budget? What goes wrong without one?
  5. Can two different plans solve the same problem? Give an example where they do, and describe how each plan would fail differently.

Mini Drill or Application​

Drill A. Pick three problems from Modules 1-4 that you found difficult. For each, write a one-paragraph plan in retrospect, then compare it to what you actually did. Did the real solution match the plan? Where did you veer off?

Drill B. Problem: Show that $\sum_{k=1}^n k^2 = \frac{n(n+1)(2n+1)}{6}$. Before executing, write a one-paragraph plan naming the heuristic (induction), the base case to check, and the algebraic simplification the inductive step will reduce to. Your plan should be short enough to read aloud in 20 seconds.

Drill C (unseen). Take a problem you have not attempted: "Prove that in every simple graph with at least two vertices, there are two vertices of equal degree." Produce only the plan -- do not prove it. Then attempt the proof and verify your plan directed you to the right heuristic (pigeonhole on degree values).

Read This Only If Stuck​