I got into computers when I was in middle school, and started learning to code in high school. My family was able to get me a computer to work and play, which made a huge difference. I tried things, failed at most, succeeded a few times, and learned a lot.
Now, I was the only person in the family interested in computers and programming. That meant that when I had problems, I didn’t have anyone else to discuss them with. No one at home understood what I was talking about. If I couldn’t work out the problem, I was stopped until then next day at school when I could discuss it with my teachers or classmates.
Fast forward to college, and I was still playing around with computers and software. My girlfriend (now wife) wasn’t a computer programmer either. She is, however, intelligent and interested in what I was working on. When I had a problem, I would discuss it with her. I found that explaining the problem to her in non-technical terms, answering her questions, and translating her answers into technical terms would often help me break through and solve my problem.
I didn’t know it at the time, but I had stumbled upon a technique known as rubber duck debugging.
The basics of rubber duck debugging are simple:
- First, get a rubber duck (see below).
- Then, when you have a programming problem, you review the code with the rubber duck.
- Explain what the code should be doing, then go over it line by line.
Often, you will find that in the process of explanation and code review, you discover the problem:
- The code isn’t doing what you expected.
- An assumption you have made isn’t valid.
- You’re not handling an error condition properly.
Once discovered, the problem becomes easy to fix.
I hear you talking…
OK, wait a minute — a rubber duck? I’m supposed to explain my problem to a rubber duck?
Yep.
How is that supposed to work?
It works because it forces you to do two things:
- Simplify the problem.
- Change your perspective to teaching.
If you’re going to explain the problem to a rubber duck, you have to give it some background. Since the duck is probably not well-versed in programming, you have to simplify things for them. This forces you to explore the problem from a different perspective, where inconsistencies and incongruities are easier to spot.
But does it have to be a rubber duck? Can’t I just talk to my partner, or roommate? Or the guy sitting next to me on the bus?
You can use anything, but traditionally rubber ducks have been used. Using an inanimate object keeps you from bothering other people, causing them to get off before the bus reaches their stop.
And once you discover the solution, you often want to implement it immediately. When other human beings see you talking to a rubber duck, that is a powerful signal for them to leave you alone.
Give it a try, and if you need a rubber duck shipped to you, follow one of the links at the bottom of this post. Full disclosure: I get a small commission if you use one of those links.