Divide and Conquer: The One Pattern Behind Merge Sort, Quicksort, and Binary Search
Flipping to the middle of a phone book instead of reading it page by page is the same trick that makes three "unrelated" sorting and searching algorithms actually one idea.
Open a phone book (or picture one, if you've never held one) and look for a name. Nobody starts at page one and reads every entry -- you flip to roughly the middle, see whether the name you want falls before or after that page, and repeat on just that half. Within a handful of flips, a book with a thousand pages narrows down to one. That halving strategy -- split the problem, solve a smaller version of it, and you're most of the way to an answer -- is called divide and conquer, and it's the same pattern underneath three algorithms that get taught as if they were unrelated: binary search, merge sort, and quicksort.
The pattern always has the same three steps. Divide: break the problem into smaller subproblems that are smaller instances of the exact same problem. Conquer: solve each subproblem, usually by applying the same strategy recursively until the pieces are small enough to solve directly. Combine: stitch the solved pieces back into a solution for the original problem.
Binary search is the cleanest example, because there's barely a combine step: given a sorted list and a target, check the middle element, and depending on whether it's too high or too low, throw away half the list and repeat on the remaining half. Each comparison eliminates half the remaining possibilities, which is why searching a million-item sorted list takes roughly 20 comparisons instead of up to a million.
Merge sort applies the same halving to sorting: split the list in half, recursively sort each half, then merge the two already-sorted halves back together in order -- the combine step here is doing real work, unlike binary search's. Quicksort divides differently: it picks a pivot value, splits everything into "smaller than the pivot" and "larger than the pivot," and recursively sorts each partition, with almost no combine step needed at the end since the partitions were already arranged correctly relative to each other.
Recognizing divide and conquer as one named pattern, rather than three coincidentally similar algorithms, is what lets you estimate performance quickly -- most divide-and-conquer algorithms land around O(n log n) because the problem keeps halving -- and spot new candidates for the same trick, like finding the closest pair of points in a plane or raising a number to a large power efficiently, without having to invent the approach from scratch each time.