Pseudocode is a way of describing a solution's logic precisely, without committing to any one programming language's syntax. It sits between a plain-English problem statement and real code — precise enough that two different people (or the same person, translating into two different languages) should arrive at the same algorithm from it. This chapter opens with two real demonstrations of what happens when that precision slips: the same vague instruction, implemented two genuinely different but equally "correct" ways.

Demonstration 1: "Remove Duplicates" Isn't One Algorithm

A specification that says only "write an algorithm to remove duplicates from a list" sounds complete. It isn't — it never says whether the surviving elements should keep their original order.

Precise pseudocode forces this decision to be made before either version gets written: ALGORITHM Dedupe(list) → preserve first-occurrence order is now unambiguous, and any programmer translating it into any language will produce Interpretation B, not a coin flip between the two.

Demonstration 2: Loop Bounds Are a Real Off-By-One Trap

Pseudocode phrased as for i = 1 to n is standard textbook convention meaning inclusive of n — but a programmer translating it directly into a language whose native loop construct is exclusive of its upper bound can introduce a genuine bug without realizing the pseudocode said anything different.

Five Concrete Situations Where This Skill Actually Gets Used

What This Course Won't Cover

This course is deliberately about designing and expressing an algorithm, not about two things covered elsewhere on this site:

• Formal complexity analysis — Big-O notation, growth rates, and proving an algorithm's efficiency belong to Algorithms & Complexity (algo1); this course focuses on getting the logic right first, not on how fast it runs
• Formal logic and proof techniques — propositional/predicate logic, direct/contrapositive/induction proofs belong to Discrete Mathematics Fundamentals (dmath1); this course uses everyday conditional/loop logic without the formal proof machinery
• Any single language's syntax in depth — pseudocode is deliberately language-agnostic; Chapter 5 covers translation patterns across paradigms, not a specific language's own full feature set

Where This Course Is Headed

Hands-On Exercises

Chapter 1 showed what goes wrong when an algorithm's description is vague. This chapter gives this course's own pseudocode a fixed, consistent notation, and covers the deeper reason that notation only needs three kinds of building blocks — sequence, selection, and iteration — to describe absolutely any algorithm, no matter how complex.

This Course's Pseudocode Notation

Every pseudocode block in this course uses the same conventions: keywords in UPPERCASE (IF/THEN/ELSE/ENDIF, WHILE/ENDWHILE, FOR/ENDFOR), ← for assignment, and indentation to show nesting — deliberately close to what most textbooks and technical interviews already use, so nothing here needs relearning elsewhere.

The Three Building Blocks

This isn't just a stylistic preference. It's backed by a real, formal result in computer science: the Böhm–Jacopini theorem (1966) proves that any computable function — however complex — can be expressed using only these three constructs, with no need for arbitrary jumps between arbitrary points in a program.

A Real, Verified Demonstration: No Goto Needed

Older languages (early BASIC, Fortran, assembly) relied heavily on GOTO — an unconditional jump to any labeled point in the program. To make the Böhm–Jacopini claim concrete rather than just cited, here's the same task — sum the even numbers from 1 to n — implemented two genuinely different ways: one using only sequence, selection, and iteration, and one built as an actual label-and-jump interpreter that mimics classic goto-driven control flow, with no while or for anywhere in its own execution logic.

Where This Connects

Hands-On Exercises

A flowchart is a second notation for the exact same three building blocks Chapter 2 covered — sequence, selection, iteration — drawn instead of written. It isn't a replacement for pseudocode; it's an alternative view of the identical logic, useful in some situations and genuinely counterproductive in others.

Standard Flowchart Symbols

Converting Pseudocode to a Flowchart — the Exact Same Algorithm as Chapter 2

Below is Chapter 2's own FindMax pseudocode, redrawn as a flowchart using only the five symbols above. Nothing about the underlying algorithm changed — only its notation.

Flowchart for FindMax(list) — every shape maps directly to one line of Chapter 2's own pseudocode

When a Flowchart Helps

• Non-technical stakeholders — a shape-and-arrow diagram is often easier for someone who doesn't read code fluently to follow than the equivalent pseudocode
• A small number of branches — a handful of decision points renders as a compact, genuinely clarifying picture
• Spotting a missing case at a glance — an arrow that visibly goes nowhere, or a decision with no "else" path drawn, is often easier to notice in a diagram than scanning indentation in text

When a Flowchart Hurts — Demonstrated by the Diagram Above

Flowcharts also handle two things this course will need soon particularly badly: recursion (a flowchart has no natural way to show a process "calling a smaller copy of itself," the subject of Chapter 9) and complex data structures (a single box like max_val ← list[0] hides everything about how list is actually organized — fine for a simple list, unworkable for a tree or graph).

Where This Connects

Hands-On Exercises

A real problem statement rarely arrives in a form small enough to write pseudocode for directly. Top-down design is the discipline of splitting a large, ambiguous problem into smaller subproblems — and splitting those, if needed — until each remaining piece is simple enough that Chapter 2's own three building blocks can express it directly.

Input / Processing / Output: A Starting Discipline

Before decomposing anything, frame the problem in three parts — what goes in, what has to happen to it, and what comes out. This alone often reveals the natural first split.

The "Processing" row is doing too much to write pseudocode for directly — that's the signal to decompose it further.

Top-Down Decomposition, One Level

Splitting "Processing" into its natural major steps produces five subproblems, each independently understandable without needing to know how the others are implemented internally:

Pseudocode for Each Subproblem — and a Full, Verified Composition

Each of the five boxes above becomes its own short block of pseudocode, using a concrete cart to ground the numbers: 3 Widgets at $12.50, 1 Gadget at $45.00, 2 Gizmos at $8.25. Discount tiers: 10% off at $100+, 5% off at $50+. Free shipping at $75+ (discounted), otherwise a flat $8. Tax: 8%.

Where This Connects

Hands-On Exercises

Pseudocode describes what an algorithm does. Real code has to also decide how that logic is organized — as a sequence of steps, as an object's own behavior, or as a chain of transformations. The same pseudocode can translate correctly into genuinely different-looking real code, and a few specific translation habits are a real, verified source of bugs when the target language doesn't behave quite the way the source pseudocode implicitly assumed.

One Pseudocode Algorithm, Three Paradigms

A Real, Verified Translation Pitfall: Truthiness Isn't Universal

Pseudocode often writes IF list IS EMPTY THEN .... A common shortcut when translating this is to rely on the target language's own "truthiness" rules instead of checking length explicitly — a habit that works in some languages and silently breaks in others.

Where This Connects

Hands-On Exercises

Once a problem has been decomposed to a subproblem small enough for direct pseudocode (Chapter 4), the very first design question is often: could I just try every possibility? Brute force — systematically checking every candidate solution until the right one turns up — is a genuine, often-correct first strategy, not a lazy fallback. This chapter shows exactly where that's true, and exactly where it stops being true, with real measured numbers rather than a rule of thumb.

Worked Example 1: Two Sum, Checked Exhaustively

Worked Example 2: A Small-Keyspace PIN Search

A 3-digit PIN has exactly 1,000 possible values (000 through 999). Checking every single one is a completely legitimate approach when the space really is this small.

When Brute Force Is the Honest Answer

• The search space is genuinely small — hundreds or thousands of possibilities, as verified above, finish in a fraction of a second
• Correctness matters more than speed, and the deadline allows it — an exhaustive check is trivially easy to convince yourself (and a reviewer) is correct, since it never skips a case by construction
• It's a legitimate first draft — a working brute-force solution, even one that will later be replaced by Chapters 7 or 8's own smarter strategies, gives a correct reference answer to test a faster version against

When Brute Force Stops Being Honest — A Real, Measured Limit

Consider a genuinely different problem: given a set of n items, check every possible subset (for example, to find one that sums to a target value). The number of subsets of a set of size n is 2ⁿ — and unlike the PIN search's fixed 1,000 candidates, this grows with the input itself.

This is the honest boundary: brute force is the right answer exactly as long as the number of candidates stays small relative to how fast they can be checked — and the PIN search and the subset search differ only in how their candidate count behaves as the input grows, not in how the strategy itself works.

Where This Connects

Hands-On Exercises

A greedy algorithm makes the choice that looks best right now, at every step, and never revisits or reconsiders it. It's fast and simple to write — and whether it's actually correct depends entirely on the problem's own structure. This chapter runs the exact same greedy algorithm on two different inputs: one where it provably matches the true optimum, and one where it provably doesn't.

The Algorithm: Greedy Coin Change

At every step, it grabs the largest coin that still fits — the locally optimal choice — and never looks back.

Case 1: Greedy Matches the True Optimum

Run on standard US coin denominations (25, 10, 5, 1), and cross-checked against a true optimum computed independently (via dynamic programming — trying every combination systematically, not greedily):

Case 2: The Exact Same Algorithm, Verified to Fail

Run the identical GreedyCoinChange pseudocode — nothing about the algorithm itself changes — on a different denomination set: {1, 3, 4}, making change for 6.

The Honest Rule for Trusting Greedy

Greedy works exactly when a locally optimal choice is guaranteed to never rule out a globally optimal solution — a property specific problems genuinely have (US coin denominations happen to; activity/interval scheduling and Huffman coding are two other classic examples) and other problems genuinely don't (the {1,3,4} denomination set above; the general knapsack problem is another well-known example). There's no way to tell just by looking at a problem casually — it has to be checked, either by testing against an independently-computed optimum (as this chapter just did) or by a formal proof (a topic for a more advanced algorithms course).

Where This Connects

Hands-On Exercises

Divide and conquer solves a problem by splitting it into smaller subproblems of the same kind, solving each one the same way (recursively, down to a simple base case), and then combining the results. Unlike greedy's single irreversible choice at each step, and unlike brute force's flat scan of every candidate, divide and conquer trusts recursion to handle the "smaller version of the same problem" part entirely on its own.

Every Divide-and-Conquer Algorithm Has the Same Three Parts

Worked Example 1: Finding the Maximum, a Structurally Different Way

Chapter 2 solved FindMax with an iterative loop. Chapter 3 drew it as a flowchart. Here's the identical problem — find the largest value in a list — solved a genuinely different way: split the list in half, recursively find the max of each half, and combine by taking the larger of the two.

Worked Example 2: Merge Sort, Split/Solve/Combine in Full

MaxOfDivideConquer's "combine" step was a single comparison. Merge sort's combine step does real work — merging two already-sorted halves back into one fully sorted list — making the pattern's three parts genuinely visible.

Why Divide and Conquer Isn't Just "Recursive Brute Force"

Where This Connects

Hands-On Exercises

Chapter 8's divide-and-conquer algorithms were already recursive — this chapter names that pattern explicitly, then builds on it with backtracking: a systematic search that abandons a partial candidate the moment it's known to be hopeless, rather than generating and checking every full candidate the way Chapter 6's brute force did.

Recursion, Formalized: Base Case + Recursive Case

Every recursive algorithm needs exactly two things: a base case simple enough to answer directly, and a recursive case that calls the same algorithm on a smaller version of the problem, then uses that result to build the current answer.

Backtracking: A Prune-as-You-Go Alternative to Brute Force

Chapter 6 verified that checking all 2ⁿ subsets of a set explodes fast — over a trillion for just 40 items. Backtracking attacks the exact same kind of problem differently: build a candidate one item at a time, and the moment a partial candidate is provably unable to lead anywhere valid, stop extending it immediately — never even generate the full candidates that would have grown from it.

Backtracking vs. Brute Force, Side by Side

Where This Connects

Hands-On Exercises

One continuous project: a conference organizer hands over a genuinely ambiguous request, and every chapter of this course gets applied, in order, to turn it into a working, verified algorithm — resolving the ambiguity, decomposing the problem, choosing the right strategy for each piece, and translating the result into real code.

Step 1 — The Problem Statement, and Its Hidden Ambiguity

Step 2 — IPO Framing and Decomposition

Step 3 — Sorting: Reusing Merge Sort Directly

Step 4 — Greedy Room Assignment, Verified Optimal

Step 5 — A Small Brute-Force Check for an Organizer's Override

Step 6 — Translating the Final Algorithm Into Real Code

What This Course Doesn't Cover

As stated honestly back in Chapter 1: formal complexity analysis and formal logic/proof techniques stayed out of scope through all ten chapters. This capstone never asked how fast any of these algorithms are, or proved greedy's optimality from first principles — it verified correctness by cross-checking against an independent computation, exactly the discipline this course built from Chapter 6 onward. Algorithms & Complexity and Discrete Mathematics Fundamentals pick up exactly where this course's own honest boundary was drawn.

Where This Course Connects

Discrete Mathematics Fundamentals' own set and logic material underlies Chapter 2's structured conditionals directly. Algorithms & Complexity would give this capstone's own greedy-optimality claim (Step 4) and brute-force cost (Step 5) precise, provable mathematical treatment. Within the new Software Development subject, Design Patterns picks up directly where this course leaves off — the same decomposed, well-named subproblems this capstone produced (sort, assign, verify) are exactly the shape a real codebase organizes into classes and modules.

Hands-On Exercises