Module 1: Algorithm Intuition: Case Studies
These cases help learners move from "the code runs" to "I can explain the process, cost, and edge cases."
Case Study 1: Finding a Name in a Signup List
Scenario: A club signup sheet grows from 30 names to 30,000. A learner scans every row to check whether a person already signed up.
Source anchor: MIT Mathematics for Computer Science.
Module concepts:
- algorithm steps
- linear search
- input size
- data representation
Wrong Approach
Assume scanning is fine because it feels instant in a small example.
Better Approach
Count the steps as the list grows, then choose a representation that matches the operation: sorted list for binary search or set/map for membership.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Linear scan | Simple | Slows with every added name |
| Sorted list | Enables binary search | Requires maintaining order |
| Set | Fast membership | Uses hashing and extra memory |
Failure Mode
The learner judges an algorithm by a toy input and misses growth behavior.
Required Artifact
Draw a step-count table for 10, 100, 1,000, and 10,000 names, then explain the better representation.
Project / Capstone Connection
Reuse this step-count habit in later algorithm and systems projects whenever you justify a data-structure or lookup choice.
Case Study 2: Recipe Steps With Hidden Branches
Scenario: A learner writes instructions for making a sandwich but forgets conditional steps: what if there is no bread, the knife is dirty, or the bread is already toasted?
Source anchor: MIT Mathematics for Computer Science.
Module concepts:
- precise instructions
- conditionals
- edge cases
- dry runs
Wrong Approach
Write instructions that only work for the happy path.
Better Approach
Perform a dry run and mark inputs, branches, outputs, and failure conditions. Turn ambiguous language into testable steps.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Natural language only | Easy to write | Ambiguous execution |
| Pseudocode | Clear control flow | Less conversational |
| Flowchart | Visual branches | Can grow large |
Failure Mode
The algorithm fails on the first input that differs from the imagined example.
Required Artifact
Create pseudocode and a dry-run table for three input conditions.
Project / Capstone Connection
Keep using dry-run tables when later project logic behaves unexpectedly; they remain one of the fastest ways to expose hidden assumptions.
Case Study 3: Guessing Game Strategy
Scenario: A number-guessing game asks the learner to find a number from 1 to 100. Random guessing works sometimes but gives no strategy.
Source anchor: MIT Mathematics for Computer Science.
Module concepts:
- search space
- halving
- invariants
- worst-case reasoning
Wrong Approach
Guess numbers based on intuition and count only lucky runs.
Better Approach
Maintain a range of possible answers and halve it each guess. State the invariant: the true number remains inside the current range.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Random guessing | Simple | Unreliable worst case |
| Linear guessing | Predictable | Too many guesses |
| Halving strategy | Efficient | Requires sorted/order assumption |
Failure Mode
The learner cannot explain why the strategy always finishes.
Required Artifact
Write the invariant, a worst-case guess bound, and a trace for target 73.
Project / Capstone Connection
Carry this invariant-and-bound pattern into later search, routing, and debugging explanations in your project writeups.
Source Map
| Source | Use it for |
|---|---|
| MIT Mathematics for Computer Science | Introductory precision, proof habits, and discrete reasoning. |