…is a method early software coders used to help debug their work.
The term stems from a book, ‘The Pragmatic Programmer‘ which relates the story of a programmer who carried around a rubber duck and used it as a sounding board to explain, line by line, what the code was supposed to do.
Though it sounds silly, it’s a process to force one to walk through ones thinking in order to clarify.
Richard Feynman used a similar method of pretending to teach any new learning he was undertaking to a child so that he could be sure he himself understood what he was learning. If he couldn’t explain it to a kid, he most likely didn’t understand it himself.
Using the Feynman technique to learn new things is, in itself, not only a useful thing to learn but brings up a different application for the practice.
Many of us have been subjected to the ten page report or the PowerPoint pitch deck that’s so full of information that the smallest font is chosen so that it fits onto the slides. We can’t actually read it but all the information is there.
In Steven Pressfield’s book, ‘Nobody Wants To Read Your Sh*t,’ he wrote “In the real world, no one is waiting to read what you’ve written. Sight unseen, they hate what you’ve written. Why? Because they might have to actually read it.”
We could take a lesson from Richard Feynman and our coding colleagues and put our reports and pitches to a pretend twelve year old, or desktop rubber duck, to see if we’ve over-complicated or over-explaned the topic. If we can simplify and clarify, someone may actually want to read what we’ve written and catch what we’re trying to convey.
Written while listening to Philip Glass’ Koyaanisqatsi (Yep, that’s a real word which means ‘life in turmoil,’ or ‘life out of balance,’ in the Native American Hopi Tribe Language.
The best thing I came across online over the last week. https://www.youtube.com/watch?v=NdbbcO35arw&t=20s&ab_channel=RSA