In software engineering, rubber duck debugging is 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. > The idea is that explaining something to a silly-looking inanimate object will force you to be as simple as possible. It reminds me of the [[Richard Feynman]] technique (see [The Feynman Learning Technique](https://fs.blog/2021/02/feynman-learning-technique/)): 1. Pretend to teach a concept you want to learn about to a student in the sixth grade. 2. Identify gaps in your explanation. Go back to the source material to better understand it. 3. Organize and simplify. 4. Transmit (optional). On explaining things simply: > It turns out that one of the ways we mask our lack of understanding is by using complicated vocabulary and jargon. The truth is, if you can’t define the words and terms you are using, you don’t really know what you’re talking about. If you look at a painting and describe it as “abstract” because that’s what you heard in art class, you aren’t displaying any comprehension of the painting. You’re just mimicking what you’ve heard. And you haven’t learned anything. You need to make sure your explanation isn’t above, say, a sixth-grade reading level by using easily accessible words and phrases. > When you write out an idea from start to finish in simple language that a child can understand, you force yourself to understand the concept at a deeper level and simplify relationships and connections between ideas. You can better explain the why behind your description of the what. > Looking at that same painting again, you will be able to say that the painting doesn’t display buildings like the ones we look at every day. Instead it uses certain shapes and colors to depict a city landscape. You will be able to point out what these are. You will be able to engage in speculation about why the artist chose those shapes and those colors. You will be able to explain why artists sometimes do this, and you will be able to communicate what you think of the piece considering all of this. Chances are, after capturing a full explanation of the painting in the simplest possible terms that would be easily understood by a sixth-grader, you will have learned a lot about that painting and abstract art in general. I like this quote: > _Any_ intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage—to move in the opposite direction. \- E.F. Schumacher Many programmers have had the experience of explaining a problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent. More generally, teaching a subject forces its evaluation from different perspectives and can provide a deeper understanding. By using an inanimate object, the programmer can try to accomplish this without having to interrupt anyone else.