Foundations
What is an algorithm?
A precise recipe, and what makes one good
An algorithm is a finite sequence of precise, unambiguous steps that turns an input into a desired output. That's it. Every sort, every search, every step of training a language model is, underneath, one of these recipes. This whole course is really about collecting good ones and understanding why they work.
The word feels intimidating; the idea is humble. A cooking recipe is an algorithm. Long division is an algorithm you already run by hand. What makes the computer-science version special is a demand for total precision - because your follower (the machine) has no common sense to fill in gaps.
The four demands
For a procedure to count as an algorithm, it must be:
- Finite - it stops. No infinite loops.
- Unambiguous - each step means exactly one thing; no "season to taste."
- Effective - each step is simple enough to actually carry out.
- Correct - for every valid input, it produces the right output (including the weird inputs).
Feel it: program the robot
Here's the whole lesson in one toy. A robot sits at the start of a corridor and must reach the 🚩 goal. Cell 3 is a pit. You have exactly four instruction blocks - three forward (move +1) and one jump (move +2, clearing one cell). Drag the blocks to reorder them, then press Run.
The blocks never change - only their order does. That's the point: same steps, different order, and the robot either arrives or falls in. Try the obvious "just go forward" ordering first and watch it crash.
Your program (runs left to right)
What you just proved
Only forward, forward, jump, forward works. Every other ordering lands the robot on the pit. Two lessons hide in that: order is part of the algorithm (the steps alone aren't enough), and the pit is an edge case - an input the naive plan didn't account for. Most real bugs are exactly this: a step order or an edge case the author never considered.
Correctness vs. efficiency
Two different questions we'll ask of every algorithm in this course:
- Is it correct? Does it reach the goal for all valid inputs - including the pit, the empty list, the single element, the already-sorted array?
- Is it efficient? How much time and memory does it cost as the input grows? That's Big-O, coming up in Lesson 2.
A correct-but-slow algorithm and a fast-but-wrong one are both failures. We want both - and we'll learn to prove correctness (with tools like induction) and measure efficiency.
# goal at cell 5, pit at cell 3
function runProgram(steps):
pos = 0
for step in steps: # order matters
if step == "forward": pos = pos + 1
if step == "jump": pos = pos + 2
if pos == PIT: return "crashed" # the edge case
return "reached goal" if pos == GOAL else "missed"Notice how the pseudocode is unambiguous: every step is a single, mechanical action. There's no "move toward the goal" - that would assume judgment the machine doesn't have. Turning fuzzy human intentions into steps this precise is the core skill, and it's called .
Check yourself
Which property is not part of the definition of an algorithm?
Recall: in your own words, why did reordering the same four blocks change success into a crash?
Try to state it, then check.
Primary source
Watch Harvard CS50x - the first lectures build "computational thinking" and precise steps from absolute zero with legendary clarity. For a gentler illustrated take on algorithms specifically, skim Chapter 1 of Grokking Algorithms.
Ask your teacher
Want me to show how long division or making tea is "really" an algorithm, or to jump ahead and prove one correct with induction? Just ask - that's what I'm here for.
Lock it in
- An algorithm is a finite, unambiguous, effective, correct sequence of steps from input to output.
- Order is part of the algorithm: the same steps in a new order can fail.
- Edge cases like the pit are real inputs a correct algorithm must still handle.
- Correctness and efficiency are separate questions; we want both, and Big-O measures the second.