How to use this book

This book teaches you to design algorithms, not to memorize them. It is built on two ideas.

Algorithms are made of primitives

A handful of simple, recurring ideas, what we call primitives, appear again and again across all of computing. A random fingerprint lets you compare two huge things by comparing two small ones. A structure that keeps spare room where the next arrival will land never has to shove anything aside to make space. A single well-chosen cut through a network proves that nothing more can be pushed through it. None of those needs the others, each one is worth a short name, and each one turns up again in places that look nothing alike.

Famous algorithms are not monoliths to be memorized. They are compositions of primitives. There is a well-known method for planning a delivery round that never ends up more than half again longer than the shortest possible route, and it is not one clever idea. It is three ordinary ones snapped together, each of which this book covers on its own, and the guarantee falls out of the joins. You will meet it by name later, once the three parts are yours. Once you see the primitives, you see the seams, and you can compose your own.

Each primitive carries an honest label: the idea, the assumption it needs, the way it fails when that assumption breaks, and its cost. Learning the failure modes is as important as learning the moves, because that is what tells you when a primitive will and will not survive being composed with another.

You will be asked to try things before you are told them

A chapter starts from a problem and hands it to you before it hands you anything else, then names the idea that solves it, usually at the exact place your own attempt ran out of road.

Two boxes carry that work:

• Try first. A boxed problem to attempt before reading on. Close the AI. Reach for a pen.
• No-AI check. An unaided problem whose whole value is that you solved it yourself.

If you are sitting in one of those boxes and nothing is coming, you are not doing it wrong. That is the box working.

Everywhere else, an AI assistant is a fair tool: feedback, examples, drill, a second opinion on code you wrote. If letting it in turns a hard task into a smooth one, it is in the wrong place.

Ten minutes of being stuck is not the tax you pay before the learning. It is the learning. Your brain keeps what it knows in the connections between its cells, and those connections are moved by work rather than by exposure: what you struggle to produce tends to hold, what you watch someone else produce mostly does not. Reading a clear explanation and nodding along feels like understanding, and that is exactly what makes it dangerous.

I know how that sounds when you are the one stuck. The students who hate this part most are, in my experience, usually the ones who end up ahead.

Two layers, and how to read

Each chapter has a core path (everything you need) and a frontier map (a short tour of where the ideas lead: vector databases, mechanism design, verifiable computation, and more). Read the core path in order the first time. The frontier maps can be skipped and returned to.

Section titles carry a mark when they are not core path, in the text and in the table of contents beside each chapter: ★ advanced, safe to skip on a first reading; ✎ practice; ◆ the big picture, where a chapter steps back and puts what it built in terms of design and primitives.

You do not have to read the chapters in numbered order. The reading paths appendix offers several routes through the same material: a short one-semester path, a systems-first path, a theory-first path, and the full course path. Pick the one that fits where you are going.

How the code is checked

All of the book’s code is public, in the repository github.com/mbrcic/algodesign. Each structure is there three ways: in Python, the version the chapters print, to read and run; in Rust, the fast one; and in Lean, where what the structure promises is stated and proved.

Every listing a chapter prints is run against the companion library whenever the book is built, and the build fails if the two disagree. The contracts chapter tells why that check exists and what it does and does not guarantee.

Some blocks are not run. A listing written as pseudocode (steps in a code-like style that no real language runs as written) leans on conventions the surrounding prose states but never defines in code. Running it would test the guesses of the harness, the program that runs the checks, rather than the book’s text, so it is checked for being well-formed and nothing more. Those blocks are marked where they appear.