--- title: "I started with binary search" description: "Before VizLearn there was AlgoV, and before that, binary search: five lines of code where every hard part is a boundary. Static diagrams could only ever show the author's input. I wanted to type mine." source: https://vizlearn.app/blog/i-started-with-binary-search date: 2026-02-18 --- # I started with binary search The first algorithm that made me want to build VizLearn was binary search, and not for the reason you'd guess. The surface idea is easy — halve the range, throw away the half that can't hold the target, repeat. You get that in one sentence. What you don't get in one sentence is the boundaries, and binary search is almost all boundaries. Is the loop `while left < right` or `while left <= right`? When `mid` isn't the target, does the next range start at `mid` or `mid + 1`? Where does the search land when the target isn't in the array at all? What happens with duplicates — the first match, or just some match? The algorithm is five lines. Four of them are edge cases, and every off-by-one I ever shipped lived in those four lines. The "fast search" part was never the hard part. The boundaries were. ## Somebody else's run When I went looking for help, the visualizations I found came in two flavors. There were static diagrams — a row of boxes, some arrows, a caption — and there were step-through players, where you click *Next* and watch the author's example advance one frame at a time like a slideshow. Both are fine at what they set out to do. Neither could help me, and it took me longer than I'd like to admit to see why. They can only ever explain the input the author picked. The slideshow walks `[1, 3, 5, 7, 9]` searching for `7` perfectly. But the case stuck in my head was *mine* — the one where I couldn't tell if it should be `<` or `<=`, the one with the target sitting just past the midpoint, the one with the duplicate. None of those was the run on the screen, and there was nowhere to type them in. That's the gap I kept coming back to, and it has nothing to do with how pretty the picture is. Understanding doesn't live in the author's run. It lives in *your* run — the one you're unsure about. A visualization that can't take your input can't reach the place you're actually stuck. ## The bug was never the algorithm So the first version of this — a project I called AlgoV, before work pulled me off it and before any of it had this name — wasn't trying to make algorithms prettier. It was trying to do the one thing those tutorials wouldn't: let me push my own input through and watch where it actually went. Type the array. Type the target. Watch *this* search, with *these* boundaries, take the path it takes. The bug, it turned out, was never the algorithm. It was the demo. And once you've felt that on binary search, you see it everywhere — worst of all on the algorithms where the final answer is trivial to state and the *intermediate state* is the entire difficulty. Knapsack's answer is one number; the understanding is why value moves from this cell of the table to that one. Dynamic programming's answer is a filled grid; the understanding is which subproblem got reused, and when. Union-find with path compression ends as a flat tree; the understanding is the instant it *snaps* flat. N-Queens ends with a board; the understanding is the search backing out of a dead end to try again. A picture of the final state teaches none of it, because the final state is the one part that was never confusing. ## The trace I didn't plan Here's the part I didn't design, and it's the part that ended up mattering most. To let you run your own input, the rendering eventually landed on Remotion — the long way round, past detours that are [their own story](https://vizlearn.app/blog/dependency-not-an-engine) — where every frame is a pure function of its number: hand it frame 212 and it computes exactly what belongs on screen at 212, the same way every time. Input was what I was chasing. But the moment your animation is a pure function of a number, you no longer have a movie — you have a *trace*: a complete, deterministic record of every step, addressable at any point you like. I didn't set out to build a debugger. The trace fell out of building for input. And once the trace existed, the real lesson arrived on its own. Letting you run your own input is necessary, but it isn't enough. If you just press play — even on your own array — you're still receiving. The thing that proves you understand binary search is not watching it run. It's being stopped one step short and made to call the move: which way does `mid` go now? Does this pass lock in index 6? You don't know the algorithm until you can predict its next step on an array you've never seen. Because the answer is sitting right there in the deterministic trace, the question can be graded against exactly what the animation does — on whatever input you typed, never a second copy of the algorithm off to the side that might quietly disagree. That turned into [its own post](https://vizlearn.app/blog/predict-the-next-step); the point here is only that I didn't plan it. Input forced the trace, and the trace handed me the prediction. ## Input, trace, predict, reveal So the shape VizLearn gradually settled into reads in one line. You put in an input. It builds a trace. It stops and asks you to predict. Then it reveals what actually happened, and you see precisely where your model was wrong. None of the four is decoration: the input makes it your problem, the trace makes the answer honest, the prediction makes you commit, and the reveal is where a wrong commitment breaks — out loud, which is the only place I've ever reliably learned anything. There are two ways into that loop, and they do different jobs. The default input you land on isn't random; [it's chosen to expose the concept on the very first run](https://vizlearn.app/blog/default-input-is-the-curriculum), so the learner who never opens the config still meets the thing that matters. Your own input is the next move — when you've got a specific boundary stuck in your head, the `<=` or the absent target or the duplicate, you type it in and challenge the concept with the exact case you don't trust. The author picks your first case; you pick the one that's actually keeping you up. AlgoV was the first crack at this, and I shelved it for a couple of years. VizLearn is the same itch, carried all the way into a product. And [binary search](https://vizlearn.app/algorithms/search/binary-search) is still the lesson I point people to first — not because it's the flashiest thing in there, but because it's where I first felt, with a specific off-by-one in front of me, that watching an algorithm and understanding it are not the same thing, and that the distance between them is about the size of an input box and one good question.