The solution files were still there. The code still worked. But I could not always remember the thought process that led to the answer.

Sometimes I would open something I had written only a few weeks earlier and need to understand it all over again. That made me realise that saving a correct solution is not the same as saving what I learned.

That small frustration became the beginning of SolveLogs.

The gap between reading and understanding

When learning algorithms, it is easy to feel that you understand something while reading it.

The explanation sounds reasonable. The finished solution looks short. The example produces the expected answer.

Then you close the page and try to solve a similar problem on your own.

Suddenly, the idea feels much less obvious.

I experienced this repeatedly. I could recognise an approach after seeing it, but recognition was not the same as being able to produce it independently.

That gap became one of the most interesting parts of building the website.

I started paying more attention to the questions that appear before the final answer:

• What information matters at this point?

• What changed after the last decision?

• Why is part of the input no longer relevant?

• What mistake would lead the process in the wrong direction?

• How can the reasoning be explained without assuming that the reader already knows it?

Those questions are often more valuable than the finished output.

The final answer hides most of the work

A completed algorithm can look much simpler than the thinking behind it.

Binary search is a good example. Its final form is compact, but a learner still needs to understand why a particular portion of the search space can be ignored.

Graph traversal has the same problem. A final traversal order tells us where the algorithm went, but not necessarily why it visited nodes in that order.

Many programming techniques become easy to memorise without becoming easy to understand.

While working on SolveLogs, I found myself returning to the same principle:

The useful part of an explanation is not only what happened, but why the next decision became possible.

That sounds obvious, but it changed how I approached the project.

Instead of treating an explanation as something placed beside the answer, I began thinking of it as the path connecting the problem to the answer.

Making something clear is harder than making it correct

One of the humbling parts of building an educational website is discovering that correctness is only the beginning.

An explanation can be accurate and still leave the reader confused.

The person creating it already knows what every term means. The reader does not. This makes it easy to skip a connection that feels obvious to the author.

The same is true for visual material. A visual can look attractive without helping someone understand the underlying idea.

This taught me to pay more attention to what a learner might reasonably misunderstand.

If a concept needs to be read several times, perhaps the explanation is carrying too much at once. If the reader reaches the answer without understanding the decision that produced it, perhaps an important part of the story is missing.

That process has also improved my own understanding. Whenever I struggle to explain something simply, it usually means I need to examine it more carefully.

Learning requires participation

Another thing I have come to believe is that reading alone is rarely enough.

A learner needs moments where they pause, predict what happens next, and check whether their reasoning was correct.

Even a small prediction changes the experience from passive reading into active learning.

That does not mean every lesson needs to feel like a game. It simply means the learner should have a reason to think before the explanation gives everything away.

This idea influenced the public lessons on SolveLogs, including the breadth-first search walkthrough. The intention is not to replace study or practice, but to make the reasoning easier to inspect before the learner tries it independently.

Building for learners changes the builder

I originally thought I was creating a place to organise work I had already completed.

Instead, the project kept showing me where my own understanding was incomplete.

It is easy to say that an algorithm “just works” when you have used it many times. It is much harder to explain its decisions to someone encountering it for the first time.

That challenge has made the project worthwhile.

Every lesson forces me to slow down and ask whether I understand the idea well enough to describe it clearly. Sometimes the answer is yes. Sometimes I discover that I only remember the usual implementation.

Those are very different things.

What SolveLogs is becoming

SolveLogs still reflects the original idea: a place where programming solutions can be revisited and understood rather than merely stored.

But it is also becoming a collection of lessons for people who want to see how an algorithm reaches its result.

I do not expect visual explanations to replace solving problems. There is no substitute for trying, getting stuck, correcting mistakes, and attempting the problem again.

The goal is to make the difficult transition from “I have seen this before” to “I understand why this works” a little less frustrating.

The most important lesson I have learned from building the site is simple:

A correct answer is useful, but the reasoning that survives after the answer is forgotten is much more valuable.

That is what I want SolveLogs to preserve.

Explore SolveLogs: https://solvelogs.com/

Here is the whole thing running on a seven-element array, searching for 16.

What the picture makes obvious

Reading the code, the halving is a claim you accept. Watching it, the halving is a thing you see happen.

Three moments stand out that I never noticed from the code alone:

Step 3 throws away four of seven elements after one comparison. values[3] = 12 is less than 16, so indices 0 through 3 are gone at once. Not one element — over half the array, from a single <. That is the entire algorithm in one frame, and it is the part the O(log n) notation hides rather than explains.

The interval, not the position, is the state. I used to think of binary search as "a pointer that jumps around." It is not. The state is [lo, hi], and mid is just a derived value you compute fresh each pass. Once the animation shows the window shrinking instead of a cursor moving, the off-by-one errors mostly stop, because you start asking "is my interval still correct?" instead of "is my index right?"

The last step is a comparison, not a discovery. At step 5 the interval is a single candidate. You still have to check it. Skipping that check is the classic bug where you return an index for a target that was never in the array.

Why seven elements matter

Seven is small enough to hold in your head and large enough to need three comparisons. A million-element array needs twenty. The animation is short, but the shape of what you are watching does not change as the input grows — that is the actual claim binary search makes, and it is easier to believe once you have watched the small version resolve.

What I am curious about

I have been building these step-by-step animations for data structures and algorithms, and I keep going back and forth on how much to show.

• Is six steps the right pace, or does it move too slowly for something you already know?
• Does the explanation text under each step help, or would you rather just watch the array and work it out?
• Which algorithm is hardest for you to picture? I find graph traversals fine and dynamic programming almost impossible to animate usefully — the table fills in, but the reason each cell gets its value is invisible.

Genuinely curious what people think. If you have seen a visualisation that made something click for you, I would like to see it.

The full walkthrough with the code in Python, C++ and Java is at solvelogs.com/learn/binary-search — free, no signup.

Somewhere in the middle of it I discovered the animations were lying to me. Here is what went wrong and what I did about it.

The problem with hand-written animation steps

My first version hardcoded every animation frame. A binary search page had a list of steps like this:

steps: [
  { lo: 0, hi: 9, mid: 4, note: "Check the middle" },
  { lo: 5, hi: 9, mid: 7, note: "Target is larger, go right" },
  // ...
]

This works right up until you change the input array. Then every frame after the first is quietly wrong, and nothing tells you. The animation still plays. It still looks convincing. It just teaches the wrong thing.

I found this the embarrassing way: a tree traversal page was animating the correct-looking sequence for a tree that no longer matched the diagram beside it. The picture said one thing, the animation said another, and both were rendered from different sources of truth.

Running the real algorithm instead

The fix was to stop writing the frames and start recording them. Each page now runs the actual algorithm and logs a snapshot at every meaningful state change:

function trace(arr, target) {
  const steps = [];
  let lo = 0, hi = arr.length - 1;

  while (lo <= hi) {
    const mid = (lo + hi) >> 1;
    steps.push({ lo, hi, mid, note: `Compare ${arr[mid]} against ${target}` });

    if (arr[mid] === target) return steps;
    if (arr[mid] < target) lo = mid + 1;
    else hi = mid - 1;
  }
  return steps;
}

The animation is now a byproduct of the algorithm, not a parallel description of it. Change the input and every frame updates. Break the algorithm and the animation breaks visibly, in the same way.

The part that actually mattered

The real win was that this made the animations testable. Once the steps come from running code, you can assert on the last one:

const steps = trace([1, 3, 5, 7, 9, 11], 7);
assert.equal(steps.at(-1).mid, 3);

I now have 1,096 of these assertions across every animation on the site. They run on every build. The suite has caught things I would never have noticed by watching:

• A heap animation that showed the sift-down but stopped one swap early, so the final heap it displayed was not actually a valid heap.
• Ten separate pages animating a linked list to explain a tree, because the generic fallback visual was easier than writing the right one.
• Several tracers truncated at exactly seven steps — a number that had crept in as a default and then silently became the ceiling for operations that needed fourteen.

That last one is my favourite failure. Every one of those pages looked finished.

What I would tell my earlier self

If a visual explanation is not generated by the thing it explains, it will drift. Documentation drifts from code for exactly the same reason, and we have long since accepted that generated docs beat hand-written ones. Animations are no different — they are just documentation that moves.

Test the output, not the rendering. I do not screenshot-test the SVG. I assert on the final state of the trace. That catches the errors that matter (wrong algorithm) and ignores the ones that do not (a node moved three pixels).

A convincing wrong explanation is worse than no explanation. A learner who reads a static wrong sentence often catches it. A learner watching a smooth animation assumes the machine knows better than they do. Getting this right felt less like polish and more like an obligation.

The result

The site is SolveLog — worked LeetCode problems and data structure lessons, each with its own generated animation. A few where the tracer approach earns its keep:

• Binary search — watch the search window actually collapse
• AVL trees — the rebalance rotations are the whole point, and they are impossible to follow as static pictures
• Backtracking — the call stack panel beside the tree is what made this click for me

It is free and there is no signup. I built it to learn this material properly myself, and the testing discipline above is the only reason I now trust it.

Happy to answer questions about the tracer architecture in the comments.