Breaker Breaker Rubber Duck

When I think about rubber ducks I think of two things. I think about Ernie singing in his bathtub and I think about the old C. W. McCall song, Convoy. And they’re both relevant here. Ernie is talking to his rubber duck. talking through his thoughts and plans. In Convoy, anti-establishment as it was, Rubber Duck, the lead driver in the convoy, recognizes that driving, as solitary as you are in the cab of your truck traveling down the interstate, is something you do with others. You’re part of group and the group does better together.

I’ve talked about Rubber Duck Debugging before. It’s the idea that a good way to start a debugging session is by explaining the situation to an inanimate object. You describe what the problem is, what you know, what you think, and the assumptions you’ve made. It gets you to be very explicit about those things and being explicit often uncovers what you missed. It might have been something you didn’t know and needed to find out. It might have been a misconception/bad assumption. It might have been a misunderstanding of what the requirements are. Or it might not help you figure out the solution, but it helped you clearly articulate the problem.

Which brings me to this Medium article. It says that rubber ducking is bad and you shouldn’t talk to that inanimate object. Instead, you should talk to a real person. That’s not a bad idea. After all, Software development is a social activity. You’re almost certainly working with others. If you’re the only person writing code, there’s others involved. Design. Sales. Marketing. Support. Even if you’re doing all that, there will be customers. Or at least users. What you’re writing and their feedback is a slow speed interactive discussion. Software development IS social.

If development is social, is it bad to talk to others on your team? No. Of course not. You should talk to the other people involved. You should talk to them frequently. About what you’re doing and why. What you need help with and what you can help others with. You should talk about the whys and the why nots.

What you shouldn’t do is substitute talking to others for thinking for yourself. Don’t bring all your problems to the team before you try to solve them. That’s what you’re there for. To solve problems. So try to do it.

That doesn’t mean you rubber duck until you solve the problem. It doesn’t mean you beat your head against the wall until one of them breaks. It doesn’t mean you have to solve every problem on your own or have all the answers right away, every time. It doesn’t mean you don’t need to put in any effort.

It means you need to try to solve the problem. It means you need to understand the problem. It means you have an obligation to bring a good question to the team when you do. And that often means rubber ducking.

How much rubber ducking is enough? Like many things development, it depends. But you always need to put in enough effort to ask a good question.