“Cardboard Programmer”, also know as “Rubber Duck Debugging” is an informal term used in software engineering for the phenomenon where describing a problem to a fellow programmer often causes you to see the solution while describing the problem. The terms come from the idea that you could achieve the same result by describing it to a rubber duck or a cardboard cutout of a person. I know from experience that it works quite often.
The usual explanation is that the process of formulating the question clarifies it in your mind thus helping you to see the solution. Supposedly some development environments keep cardboard figures or things like teddy bears or rubber ducks around for this purpose, although I’ve never seen this myself.
It strikes me that this phenomenon can’t be solely limited to software development. It must be recognized and utilized in other fields. So my question is, is there a more generic term for this phenomenon that isn’t related to any particular field? Also, do other fields have other names they use for it?
I don’t know if there is a common name for it, but one of the uses of therapy dogs for children with speech or reading difficulties is to have the dog be an “audience” for the child when practicing. While dog provides rapt, but non-judgmental attention to the “performance” that encourages the child to keep going without being embarrassed like they would be in front of a teacher or peer.
Funny that you mention dogs. Just today my Scrum Master (sort of a team leader) said something like “always ask your dog first”, which of course was a reference to this phenomena.
However, while it’s a wonderful thing for those children, I don’t think what you’re describing is the same thing.
I’ve never heard it called cardboard programmer debugging, or anything else for that name, but I am definitely well aware of the technique. I used to use it all the time with my former boss (before he retired). I would go over to his office and explain the problem I was having, and usually by explaining it I would either figure out what was wrong or at least find a new path to explore. We both knew that he had been out of programming for so long that he probably wouldn’t be able to give any practical programming advice, but we both knew the technique worked so we used it often.
I’ve never heard any particular name being given to the technique, but it’s a good problem solving technique in general. It basically forces you to step back and go piece by piece through what you are working on, which forces you away from looking at the problem in one particular detail. Often the broader view will either give you the solution or at least will point you roughly in the right direction.
I wonder (this is speculative, but still) if there isn’t a neurophysiological reason this is effective. I know when I’m head-down grinding over a debugging situation, I’m not engaging other parts of my brain that I do in formulating a verbal description. The shifts in neural activation, and the resulting changes in thought pattern, might contribute to the effectiveness of this.
It’s sort of a variant on the concept that if you really want to learn something, teach it.
Having to basically present it to someone else makes you organize your thoughts and figure out what’s important, and that’s true whether you’re teaching, talking about a programming problem, or just trying to figure something out.
I find that it helps me to just talk out problems out loud while in the car- I get a lot of the same mental organization benefits without actually having to get a cardboard cutout or bug someone else.
I have been a programmer for 26 years and have not heard the terms in the OP, but have experienced the process often.
One person I used to work with would come to my office, rapidly describe the problem, arrive at the solution, say “Thank you for being a mannequin” and leave. This happened maybe once a week.
Sure there is a neurophysiological explanation for it, in the same sense as there an explanation for what one your programs is doing in terms of how the electrons are moving around in the computer’s circuits. If you actually want an explanation you can understand and use, however, that is not where you want to go. What you want is a cognitive level explanation.
I would be very surprised if there are not cognitive theories, and, probably, experimental cognitive psychological studies, of this phenomenon out there. Unfortunately, however, I do not know what name it is standardly given amongst psychologists, so I do not know how to look it up.
When I write a paper I always try to present the results in a seminar. Sometimes I find errors, but I always improve the exposition, usually simplify significantly and come to understand better what I actually did. It wouldn’t work to lecture to a cardboard audience or a duck; it is the necessity of doing it in public that concentrates my mind.
I also know it as “rubber duck debugging”. A few years ago at the Embedded Systems Conference, one debugging-related company was giving out little rubber ducks with their logo on them to put on your monitor and to help with debugging. So it’s at least widely enough known that they figured people would get the joke.
I often find that I discover the (possible) cause when, after describing the bug, I’m listing the things it can’t be (because I’ve tested for them) and I realize that there’s something I haven’t tested for, or that one of my tests was not as conclusive as i’d like.
I sometimes ask colleagues to “be a rubber duck” for me.
Same here (give or take a year and I am retired). However, I can’t see it working well with non sentient programmers. You need to believe that the person is listening and that you need to organize your thoughts in a manner they will understand. Also, your partner may ask questions, which will also help to clarify your thoughts. Whenever I did this, I went to the person I respected the most because the technique is not 100%. Sometimes that person does solve your problem, or at least helps in a non trivial way.
I’ve never talked to a cutout or a toy, but I have experienced it while typing a question in an email, either while typing it or shortly after clicking “send”.
I’ve also had it happen when talking to a person without any back and forth. Once you get into back and forth then it’s a different process from what I’m talking about.
I think you simply have to make an effort to formulate a question that more or less fully describes the problem. So I could see it working with a toy if you pretend that it can understand you and describe the problem as you would describe it to a colleague.
I don’t think there is much physiological about this phenomenon. I think that the act of explaining the problem to someone else forces you to think through the problem. It is one of the benefits of writing proposals for anything from bidding on painting a house to going to the moon.
Obviously it’s more helpful if you’re talking to a real, intelligent person who can ask questions or offer actual advice. But there’s still some benefit to be gained from talking to an inanimate facsimile.
I have an even more efficient way. I keep an Emacs window open, which I use for notes on whatever I’m doing. I sketch new code there, copy and paste test cases, output, whatever. And make jokes. It makes Finnegan’s Wake look like Fun with Dick and Jane.
I’ve found that when I write high level pseudocode I very often (in fact usually) find logic errors and stuff I’ve missed long before I write line 1 of code.
Telling someone else doesn’t work for me because very few people here can code at all, and none have done it even half as long as I have.
I’ve never heard the term cardboard programmer, but I can see it.
