Building SolveLogs started with a simple personal problem: I had solved many programming questions, but returning to them later was surprisingly difficult.
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.
Structures like AVL trees and segment trees made this especially clear. Their rules are short to state and genuinely hard to picture until you watch the rebalancing happen step by step.
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.
