The texts that taught me algorithms

I've been carrying four books around for ten years. They are well-thumbed, marked up, re-read at uneven intervals. None of them replaces the others. Collectively they are the most valuable library any working engineer can keep on a shelf. This essay is about what each one taught me, in what order, and what it still teaches me when I open it today.

The books are Introduction to Algorithms by Cormen, Leiserson, Rivest and Stein (universally known as CLRS), Steven Skiena's The Algorithm Design Manual, Robert Sedgewick and Kevin Wayne's Algorithms, and Antti Laaksonen's Competitive Programmer's Handbook. If you own only one, it should be Skiena. If you own two, add Sedgewick. If you have patience, add CLRS. Laaksonen is the cheat code if your goal is contest programming.

Skiena, the book that teaches taste

The Algorithm Design Manual is the book I recommend to working engineers first. Skiena's organising insight is that algorithm problems are chosen, not solved. The first half of the book is a gentle, example-rich walkthrough of the standard algorithms. The second half (the "catalogue") is a reference in which each entry describes a problem and tells you which algorithms it corresponds to, what variants exist, and which library implementations to use. Nothing else reads like it.

What Skiena gets right is the moment of recognition. When you have a new problem and do not yet know what to Google, the catalogue lets you describe the shape ("all-pairs shortest paths on a dense graph", "set cover with weighted elements") and read your way to the algorithms. It is a book about connecting real questions to their literature, which is a more useful skill than knowing any particular algorithm.

The "war stories" at the end of each chapter (autobiographical notes from Skiena's consulting work) are the best case studies in any algorithms text. They show that in real projects, the choice between two O(n log n) algorithms often matters more than the theory suggests, and that the wrong representation can turn a tractable problem into an untractable one.

Sedgewick, the book that teaches implementation

Sedgewick and Wayne's Algorithms is the most polished implementation text in print. Every algorithm is presented with a clean, idiomatic Java implementation that is simultaneously readable, efficient, and pedagogically correct. The book's voice is calm and almost architectural, there's a right way to lay out a sorted-linked-list implementation, and Sedgewick shows it.

What I learned from Sedgewick is the craft of writing algorithms as code, not as pseudocode. The difference matters. Pseudocode permits ambiguity at every level, type, loop invariant, termination. A real implementation forces you to commit. When Sedgewick writes a heapsort, every decision is explicit, and you can paste the result into a production codebase without shame.

The companion online site with runnable implementations, data, and visualisations is a gift. If you are the kind of learner who needs to see code execute, start there.

CLRS, the book that teaches rigour

CLRS is the reference. It is encyclopaedic, unopinionated, and mathematically rigorous in a way that the other books are not. If you want to understand why an algorithm works, to trace the amortised analysis, to read the correctness proof, to see the lower-bound argument laid out. CLRS is the text that does it properly.

CLRS is also the book that makes everyone feel inadequate on first encounter. It's a reference, not a pedagogical text. Reading it cover to cover is miserable; using it as a lookup when a particular proof is needed is extraordinarily valuable. The usual failure mode is to start CLRS at chapter one and give up around Red-Black Trees. Don't. Skiena or Sedgewick builds your intuition; CLRS sharpens the parts that need sharpening.

The chapter on amortised analysis alone justifies keeping the book on your shelf. Three distinct methods (aggregate, accounting, potential) with worked examples, presented the only place I know of that really makes them click.

Laaksonen, the book that teaches contest craft

If you are preparing for competitive programming, the Competitive Programmer's Handbook is better than any of the above. Freely available online, tightly written, and focused on the idioms that actually appear in contests: segment trees, rolling hashes, sparse tables, convex hull tricks, the full catalogue of graph algorithms at contest speed.

Laaksonen's writing is utilitarian in the best sense, no belaboured explanation, no excess ceremony. An algorithm is named, its complexity is stated, a clean implementation follows. It is a reference for people who already know what they are looking for.

For a working engineer, Laaksonen is less useful than Skiena or Sedgewick, because the techniques are optimised for problems that only appear in contests. But if you want to see how fast the canonical algorithms can actually be made (and how small their implementations can be) the handbook is uniquely illuminating.

A reading order

If you are starting cold and want a roadmap: read Skiena first, end to end, slowly. Skip the proofs; focus on the catalogue and the war stories. Six months. Then, as a companion to writing real code, keep Sedgewick open, pick an algorithm, read Sedgewick's implementation, re-implement it in your language from the description rather than by copying. Another six months.

At that point, you have seen every important algorithm twice, once as a conceptual sketch and once as production-grade code. This is when CLRS earns its keep. Pick specific chapters (amortised analysis, dynamic programming, NP-completeness) and read them closely. Reading CLRS earlier in the journey is possible, but painful and low-yield.

Laaksonen is for when you want to see the techniques at contest pressure. Not before you can already solve most Leetcode mediums; not needed if your goal is industrial rather than competitive.

What I still open today

In practice, the books I open now are Skiena (when I need the catalogue) and the Laaksonen handbook (when I need a fast implementation of something like a segment tree). I open CLRS perhaps once every two months, almost always to re-read a specific proof. Sedgewick sits on the shelf as comfort, the physical weight of it is a reminder that someone has written the ideas down properly.

The best evidence that a book has taught you something is that you still reach for it a decade later. By that test, all four hold up. None of them is a substitute for reading code (Redis source, CPython source, the Linux kernel's data structures) but they are the conceptual scaffold that makes reading that code productive.

Where to go from here

If you are using AlgoMastery to learn the basics, treat the modules as the pedagogical layer and these books as the reference layer. When a module leaves you wanting more proof, open CLRS. When you want to see code done cleanly, open Sedgewick. When you want to recognise the shape of a new problem at a glance, keep Skiena within reach.

And when you are ready to go beyond the basics, the next essay series on this site will walk through specific chapters of each book, applied to real engineering problems. That's the long-term roadmap for AlgoMastery, an opinionated, chapter-by-chapter commentary on the texts worth reading.