If you're a programmer, have you ever found yourself talking to yourself to understand what your code is doing or to identify where a certain error is occurring? This debugging method is quite well-known, and programmers often debug with a "rubber duck." It may sound crazy, but it's a software engineering method. Debugging with a rubber duck refers to a story from the book "The Pragmatic Programmer" (which I highly recommend reading) where a programmer carries a rubber duck and debugs their code by explaining it, line by line, to the duck.

I have done it, and I know that many programmers have had the experience of explaining a programming problem to someone else, possibly even to someone who knows nothing about this universe, and magically finding the solution during the explanation of the problem.

But how is this possible? By describing what the code should do and observing what it does, any differences between these processes become clearer and more noticeable. In general, explaining or teaching about a particular subject forces you to understand the case from different perspectives, aiding in the understanding of the problem.

But does it have to be a rubber duck? No, of course not. It can be anything. The duck is used as a representative figure in the book. Personally, I explain most of my code problems to a coworker or my little toy duck, Patolino, who sits at my desk.

The tip is: you can use a rubber duck or any other discreet object you can talk to (yes, programming is like that, folks, you have to be a bit crazy).

The Explanation

It does work, and there is a whole psychological study behind how all of this works. The summary is that when we speak out loud, our brain can process the details better, and as a result, our attention to details or errors becomes sharper, allowing us to find problems more quickly.

The figure of a rubber duck, which we assume knows nothing about programming or any particular subject, requires us to explain in more detail what we are thinking when writing that block of code. By doing this, we are forced, while explaining the problem, to pay more attention to what we were previously doing alone.

Well, that's all! Thank you for reading, and here's the link to the book The Pragmatic Programmer.