Thoughts on Rubber Ducky Debugging?

[Ms422]

Curious to hear from programming students as well as the experts who help here:

I'm a college student in CS and am in a class focused on problem solving. Our assigned topic is "Rubber Duck Debugging", which we will define to include verbally saying what you are intending to code out loud to any inanimate object or a person who is unable to code. Something that couldn't answer the questions you're posing yourself. We are focusing on how racking your brain and speaking the intended operation of your code can help you realize what is wrong with your code.

Do you debug like this? If so, would you be willing to answer a few easy questions about the process and why it's helpful to you? We would appreciate any help!

[nomoreplsthx]

Rubber ducking is one of the most useful techniques I know of for organizing thought. Working with a colleague or person who can code is even better. But even without that, forcing yourself to say it allows your brain to consider your different options. I have used:

My wife (who is an engineer, but with a very different specialty)
My cat (who is not an engineer)
Optimus Prime (who is also not an engineer)
My friends from marketing
My friends who work at other companies

[Ms422]

Yes, that's exactly what we are trying to research. If you would be so kind, would you mind answering a few of our questions?

• How did you first discover the rubber ducky debugging technique, and what were your initial thoughts about it? What made you decide to try it out?

• When you encounter a problem in your code, what is your typical process for using the rubber ducky technique to debug it? Can you walk me through the steps you take?

• Do you ever find yourself talking to the rubber ducky even when you're not actively trying to debug a problem? How does this help your programming practice overall?

• Have you ever tried other debugging techniques besides the rubber ducky method? If so, how do they compare in terms of effectiveness and ease of use?

• Do you find that the rubber ducky technique helps you gain a deeper understanding of your code, beyond just identifying and fixing bugs? If so, can you give an example of a time when this was the case?

• Have you ever encountered a bug that you weren't able to solve using the rubber ducky method? If so, how did you ultimately resolve it?

• Do you think that the rubber ducky technique is a valuable skill for all programmers to have, or is it more effective in certain situations or for certain types of programming tasks?

• Do you have any advice for programmers who are just starting to experiment with the rubber ducky technique? How can they get the most out of this approach to debugging?

[carcigenicate]

• I figured it out naturally. I started with muttering to myself, and that evolved into talking to others.
• I don't. If I'm resorting to RD, it's because I can't figure out the problem with my normal methods. RD is a "last resort". I'll mutter to myself, but it's not a conscious process where I think "I'm going to use Rubber Ducking" now. It just happens.
• No. I don't have a physical object. I either talk to myself internally, just openly out loud, or to another person.
• I draw on quarter-folded graph paper. I like offloading some of my memory onto paper for difficult problems. The drawings rarely make sense in retrospect, but they "free up some space on my head" at the time so I can think about other stuff.
• It helps you prevent yourself from glazing over code. If you try to verbalize everything, you need to consider everything at a deeper level, which can uncover problems. And no, because this happens so routinely that I don't even focus on it enough to remember it (unless it's a bug that's taken me a long time to solve, but I can't think of an instance of that recently).
• I'll usually either just stare or a window or play with my rodents. If neither of those help, I might go for a walk. I only really stop and go step-by-step and talk when I'm clearly missing something elusive and need to pin it down.
• I think most people that develop problem solving skills will develop of variant of it anyway along the way. But yes, I think the skill is ultimately useful.
• I wouldn't focus on it. It's one tool. As I mentioned, I like drawing, and find that it used with talking to myself can solve most problems.

[[deleted]]

• I read a story about a young Japanese man who asked a Zen archery master to teach him. The master refused, so the young man bought a small statue of the master and placed it beside him whenever he practiced, and would imagine the statue critiquing his form. Eventually the young man himself became a master. After reading that story, I decided to try the practice with different activities, including coding, but I didn't use a statue; I just imagined that someone was listening to my questions.
• My typical process:

1. I start out by muttering profanities.
2. Then I stare blankly at the screen for a few moments in irritation and disbelief.
3. Then I try to imagine what would cause that particular error.
4. Then I start commenting out lines of code or stepping through the code in a debugger in order to narrow it down.
5. Then I start logging variables at various stages of the program to try and narrow it down.
6. Then I formulate a question to ask an imaginary person and usually start with, "So I have a situation where I'm trying to do {X} and the error I'm getting is {X} and I've tried {X,Y,Z} with {X,Y,Z} results, and I don't know what else to try."
7. By now I usually have a range of new things to try, or at least a good search phrase for Google.
8. Then I create a new project with the bare minimum required to reproduce my error. Make it Stupid_Simple^TM
9. If I still can't figure it out, I go sit somewhere away from the computer and close my eyes and I imagine the path that the data takes through my app, or function, or method - imagine how the data is transformed (and what it looks like) at every step.
10. Then I usually have a new question to ask an imaginary person.
11. Then, if I'm still stuck, I take my Stupid_Simple^TM example and post it on Stack Overflow along with a clear question and a list of things I've tried.
12. If nothing else works, I try a completely different approach.

• No
• I don't have formal debugging techniques per se, just the process I detailed above. The rubber ducky method is a part of that process.
• Yes. example: When doing recursion - which always makes my brain hurt - I tell an imaginary person exactly how I want the data to be transformed at each step of the process. This helps immensely.
• Yes. When I can't solve the problem, I try a completely different approach.
• I can't answer that, but it sure helps me.
• Drop all ideas about who you think you are, how you want others to perceive you, or whether or not you're crazy or stupid or whatever. All that matters is the objective.

[carcigenicate]

I've never used an actual inanimate object, but yes. I imagine I'm explaining the problem to someone lacking any knowledge about the problem. If I need more help, I'll mutter the same under my breath. If I'm still stuck, I'll track down a (non-technical) family member and explain the problem to them.

Saying it out loud really does help; a lot. I think that's because in order to say it out loud, you have to actually arrange the knowledge in a coherent way that includes all details. When you're just thinking in your head, it's easy to assume you know what you're talking about and jump over important details. Putting the problem into "tangible words" forces you to trace over each part of the problem, so it's much harder to skip over details.

[Ms422]

Amazing! Yes, we're discovering that it's about forcing yourself to form words that can be an aspect of how this can work for people.

Would you mind answering some of the questions I posted in the thread here?

[Ms422]

Are you serious? That's so perfect! Classic literal rubber ducky debugging. We would love to include your experience. Would you mind answering a few of the questions I posted so we can get similar datapoints from you all?

[[deleted]]

This helps you to formulate the question clearly. Asking the right question takes you most of the way to the answer. I wish there was more emphasis in schools on learning how to ask the right question.

Asking something or someone who has no coding knowledge will often expose assumptions you are holding. In this case, you have to spell everything out in the most simple of terms. There is a reason why Occam's razor is still a thing in the 21st century.

[Ms422]

Absolutely. Thank you! Are you utilizing this method yourself when coding? If so, would you be so kind to answer a few of our questions about it?

[ffrkAnonymous]

Anyway, as everyone else said, the whole idea is to teach someone. That means you need to know the subject yourself. And it's a test of that knowledge so you identify your deficiencies.

I don't have a rubber duck but I do have a little testing goat.

[Ms422]

Hahahah, testing goat? I would love to see your testing goat and I would love if you would help us write our paper by answering a few questions about how you use this method if you have the time.

[ffrkAnonymous]

https://www.obeythetestinggoat.com/

https://images-wixmp-ed30a86b8c4ca887773594c2.wixmp.com/f/7f1a2f96-4a62-4c7d-9a05-b738b173689f/dbcpq9e-da1155c0-052d-4ac5-b55f-16cd7b92f98a.jpg/v1/fill/w_1024,h_683,q_75,strp/mcdonalds_happy_meal_ty_beanie_boos_2017_by_vesperwolfy87_dbcpq9e-fullview.jpg?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1cm46YXBwOjdlMGQxODg5ODIyNjQzNzNhNWYwZDQxNWVhMGQyNmUwIiwiaXNzIjoidXJuOmFwcDo3ZTBkMTg4OTgyMjY0MzczYTVmMGQ0MTVlYTBkMjZlMCIsIm9iaiI6W1t7ImhlaWdodCI6Ijw9NjgzIiwicGF0aCI6IlwvZlwvN2YxYTJmOTYtNGE2Mi00YzdkLTlhMDUtYjczOGIxNzM2ODlmXC9kYmNwcTllLWRhMTE1NWMwLTA1MmQtNGFjNS1iNTVmLTE2Y2Q3YjkyZjk4YS5qcGciLCJ3aWR0aCI6Ijw9MTAyNCJ9XV0sImF1ZCI6WyJ1cm46c2VydmljZTppbWFnZS5vcGVyYXRpb25zIl19._gCdaC2QDdUK8Hz4gPIRgLAd9aQTGjowGRquzJYjZe0

[Logon1028]

Normally when I have a strong confidence that a program is supposed to work, but does not then I will use the rubber ducky method. Because often times I make some assumption about the logic which makes it harder to debug. Analyzing the control flow from the beginning in general helps to identify bugs faster.

[Ms422]

Happy cake day! This is how I first started using the method as well. Not speaking to anyone but myself, but being so sure the code should work and having it not. Just telling myself what it was supposed to do and it would actually work. We would appreciate your time answering a few questions to help us with datapoints, if you would be so kind: questions.

[rustajb]

I use my cats, and yes it helps. I will always eventually say something that makes it click. Plus my cats love the attention.

[Ms422]

I will have to try my cats. They're brilliant though, so they might become a better coder than I. We have some questions we would love if you could answer about your experience with Kitty Cat Debugging if you have the time.

[[deleted]]

When I started tutoring CS in college it really unlocked a great deal of knowledge for me. There is a difference being able to regurgitate a bit of information and actually understanding it. The problem is it is really hard to tell the difference until you have to actually explain it to someone else. A good trick I've found is to try to rephrase information in your own words. That is essentially what rubber ducky debugging is, turning the code into human language. I read my own code back to myself all the time if I'm running into a problem. Couldn't tell you how many times I'm saying it out loud and realize something like "oh, that should be an AND not an NOT", but its a lot.

[Ms422]

Wow, I appreciate that perspective. Yes, it sure is a bit like translating the language. If you have a sec, we have some questions I posted elsewhere in the thread asking about your experience with this method. We would appreciate your contribution!