There is a debugging technique that sounds silly at first, but works surprisingly well: rubber duck debugging.

What makes it so appealing is how little it requires. You do not need special tools, extra hardware, or even another person. You can try it almost anywhere. If necessary, you can even print your program on paper and debug it away from the screen.

Why a rubber duck? In the West, a rubber duck is a common bath toy, something many households would recognize instantly. Since the method came from that context, the name stuck.

Here is how it works.

1. Get a rubber duck. Borrow one, buy one, make one, somehow obtain one.
2. Put it in front of you. The usual setup is on your desk, beside your monitor, or near your keyboard—anywhere directly in front of you, facing you.
3. Open your source code, whether on screen or printed out.
4. Then explain your code to the duck, line by line, carefully and completely. The key is to explain, not merely recite. You need to articulate your thinking, your intent, your logic, and the reasoning behind what you wrote.
5. While explaining everything to this silent duck, you will often notice that your ideas and your actual code do not quite match. That is usually where the bug reveals itself.
6. Once you find the bug, do not forget to thank the duck.

If this sounds stupid, childish, or downright ridiculous, that reaction is understandable. Anyone doing this out loud may look a little unhinged. But the method really does work.

At its core, this is an early form of code review.

Once a problem is described in sufficient detail, its solution is obvious.

In other words:

Once a problem has been described with enough detail, the solution becomes self-evident.

Most programmers have had the same experience: you are stuck, you cannot figure out what is wrong, so you start asking someone else for help. But before you even finish explaining your idea, your intention, or the background of the issue, you suddenly discover the cause yourself. That moment is exactly what rubber duck debugging is designed to trigger.

The duck itself is only a device, a form. The real goal is self-review: forcing yourself to examine your own code by explaining it clearly enough that inconsistencies become obvious. The rubber duck simply gives you something to talk to, so you do not feel quite as strange as if you were talking to yourself. Well, perhaps only slightly less strange.

So the real substance of the method is still code review—just done by yourself, out loud, in a disciplined way.

And if you cannot find an actual rubber duck, a coworker or a friend can serve the same purpose. That said, they may be less useful than the duck. People tend to interrupt, offer opinions too early, and throw in comments while you are still trying to explain the problem, which can be annoying. The great advantage of the duck is that it listens without interfering.