Written Rubberducking: My Debugging Superpower

"Hey Duck, I'm getting this compile error in my code.

"It doesn't make any sense because the code is so simple.  The error is on the line where I calculate the HiredDate.  The function I'm calling to do the calculation returns a Date type.  That's not the problem because I've declared HiredDate as a Date variable up here at the top of the procedure... Oh, wait a minute.  I actually declared it as HireDate not HiredDate.  I see the problem now.

"Thanks for the help, Duck!"

The Concept of Rubber Duck Debugging

From Wikipedia:

The name [rubberducking] 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. ...

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.

As the name and background story imply, the traditional act of rubberducking involves speaking to an inanimate object.

The Benefits of "Written Rubberducking"

While speaking has the advantage of immediacy and expediency, the practice of rubberducking is better in almost every other way when you perform the exercise in writing.

On his blog, StackOverflow co-founder Jeff Atwood includes the following excerpt from the book 59 Seconds: Think a Little, Change a Lot, by Richard Wiseman:

From a psychological perspective, talking and writing are very different. Talking can often be somewhat unstructured, disorganized, even chaotic. In contrast, writing encourages the creation of a story line and structure that help people make sense of what has happened and work towards a solution. In short, talking can add to a sense of confusion, but writing provides a more systematic, solution-based approach.

In addition to the advantages of spoken rubberducking, the written approach confers many benefits:

• Focuses your thinking
• Builds reference material (for you and others) in case the same error reappears
• Helps others get up to speed quickly on what you’ve tried and where you’re having trouble if you need help
• Helps you get up to speed quickly if you get interrupted while debugging and have to come back to it later
• Justifies time spent on an issue (for your boss or client)

In tomorrow's article, I'll provide an actual example of this concept in practice.

UPDATE [2023-07-06]: As promised, here is a link to the article with the practical example:

Cover image created with Microsoft Designer