As I learn to code, there are many times that I just cannot go on. I just cannot solve this error, sometimes for days. Sometimes when I stop to complain to somebody about why the code is not working, I finally understand the problem. By mouthing out loud the problems I was facing, I reached a higher understanding, or considered something I had not yet tried.
If I had a mentor of some sort, I suppose this would not be needed, as at that point I would have a knowledgeable person who can talk through the code with me. But if nobody near you understands code, It ends up being just the nearest friend who will listen. I will complain for hours to my friend James about what I cannot do, only to find out that it helped me find a solution. This is great, as long as you have a person who is willing to listen to nonsense they don’t understand and can’t reciprocate. Most people enjoy conversation, rather than being mindless reservoirs for code-complaints.
It turns out that a living person is not even needed. I actually became more knowledgeable about the code i wrote, by explaining out loud what it is supposed to do, then reflecting on what it is actually doing. This has been recognized as an informal term called Rubber duck debugging.
Rubber duck debugging is an informal term used in software engineering for a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.