Tag: The Pragmatic Programmer

Rubber Ducking

One day after writing the previous post, I noticed two things:

  • I forgot to add the link for the term “rubber duck”, and
  • I never posted about “rubber ducking” before

I’ve fixed the first so it’s time to fix the second. Still finding it weird that I haven’t done it yet in the 2+ years this blog has been up, though…

Anyway, “rubber ducking” is a simple mind hack popularized by The Pragmatic Programmer. Instead of committing copyright infringement by copy-pasting what the book says about it (all 3 paragraphs), I’ll just go with Wiki Wiki’s take on the topic.

Place a rubber duck on your monitor and describe your problems to it. There’s something magical about stating your problems aloud that makes the solution more clear.

So yeah, my MO at hackathons is to either code something totally unexpected, or just float around “magically” solving problems by being a sounding board.

Angry Monkeys

Go near that stepladder again. GO NEAR THAT STEPLADDER AGAIN. I dare you, I double dare you, motherfucker. Go near that stepladder one more goddamn time.

As a follow up to Cargo Cult Thinking and Best Practices, I’d like to share a story used by Dave Thomas (one of the authors of The Pragmatic Programmer) in a keynote Angry Monkeys and Cargo Cults.

I first heard this story from Neal Ford’s presentation on ways to improve your code. Fortunately, the presentation is a short run down of his book The Productive Programmer and this allows me to copy-pastequote the book instead of having to narrate it using my own words.

Back in the 1960s (when scientists were allowed to do all kinds of crazy things), behavioral scientists conducted an experiment where they placed five monkeys in a room with a stepladder and a bunch of bananas hanging from the ceiling. The monkeys quickly figured out that they could climb the ladder and eat the bananas, but every time the monkeys got near the stepladder, the scientists would douse the entire room in ice cold water. You can guess what that generated: angry monkeys. Soon, none of the monkeys would go near the ladder.

Then the scientists replaced one of the monkeys with a new monkey, who had not been subjected to the blasts of water. The first thing he did was make a beeline for the ladder, and all the other monkeys beat him up. He didn’t know why they were beating him up, but he quickly learned: don’t go near the ladder. Gradually, the scientists replaced the original monkeys until they had a group of monkeys who had never been doused with cold water, yet they would attack any monkey that approached the ladder.

The point? In software, lots of practices on projects exist because “that’s the way we’ve always done it.” In other words, because of angry monkeys.