Engineering May 2026 5 min read The Essay

My Wife Has Been Doing This for Years. Developers Call It Rubber Duck Debugging.

A 503 error. Hours of recursion, delays, and jitter. Nothing worked. Then I called a friend just to vent... and the answer appeared the moment I put down the phone. There is a name for this. And apparently, women figured it out long before programmers did.

When your wife says "I do not need your solution, I just want you to listen to me"... there is a scientific reasoning behind that sentence. I know this now. I learned it the hard way; through a 503 error and a friend named Naresh.

I was working on a piece of code that used several of Google's APIs. At some point it started throwing a consistent error:

⚠

503: Service Unavailable

The particular challenge with this error: Google's services are rarely unavailable. So very few developers encounter it, very little has been documented about handling it, and there is almost nothing to find when you search for solutions. I was building the error handler from scratch; from a blank.

I spent the morning trying everything I could think of:

Attempts made, in order

Added retry logic with exponential backoff... still failing

Introduced recursion with a depth limit... still failing

Added deliberate delays between retries... still failing

Introduced jitter to the retry intervals to avoid thundering herd... still failing

Reviewed the API quota limits, authentication scopes, rate windows... nothing wrong

Nothing. The error persisted. The service was clearly available; everything else in the system worked. Only this one operation kept returning 503 intermittently; and the error handlers I had added were not catching it.

I was frustrated. Not the dramatic kind of frustrated where you throw something; the quiet, exhausted kind where you have stared at the same code for so long that you genuinely cannot see it anymore. So I called Naresh. Not to get help. Just for a chat; the kind of call you make when you need the company more than the answer.

I told him what I was working on. I explained the error. I walked him through, step by step, every change I had made that morning; the retry logic, the jitter, the recursion, the delays. He listened carefully. He could not figure out why the error was persisting either; my handlers looked correct to him as well. We agreed to get on a proper call in fifteen minutes, pull up the code together, and look at it fresh.

I put down the phone.

And immediately... not after thinking, not after coffee, immediately... it struck me.

I had been modifying only the main function. It did the heavy processing, so naturally I assumed that was where the error was. But I had two smaller utility functions that were purging files in real time. I had added error handlers everywhere except those two quiet little lines.

I did not need Naresh on a second call. I added the error handlers to the purge functions; two lines of code; and the system ran perfectly. It has been up and running without interruption for the last seventy-two hours.

When I told Naresh what had happened, he laughed and said: "That is rubber duck debugging."

A bright yellow rubber duck sitting on a developer's desk beside a keyboard, the laptop screen showing code behind it... the classic symbol of rubber duck debugging — The duck does not answer. That is exactly the point. It listens; and you solve it yourself.

The concept

Rubber Duck Debugging

The practice of articulating a problem out loud... to another person, to a rubber duck on your desk, to yourself in a mirror... in natural spoken language. The act of forming the explanation forces you to reconstruct the problem from first principles; and in that reconstruction, the gap you missed becomes visible. The listener does not need to understand the code. They need to receive the explanation. That is enough.

The reason it works is specific. When you are deep inside a problem, you stop seeing the full system. You fixate on the part that feels most significant... in my case, the main function... and mentally deprioritise the supporting pieces. Explaining the problem to someone else forces you to describe the entire system; not just the part you are stuck on. And in that description, the part you forgot to mention becomes the part you suddenly remember.

You do not need the other person to solve it. You need them to make you explain it.

Which brings me back to where I started. When your wife says "I do not need your solution, I just want you to listen"... she is not asking for less than you think she is. She is asking for exactly the right thing. She needs to articulate the problem. She needs a receiver for the explanation. She has known, intuitively, that the act of speaking it out loud is what helps; not the advice at the end.

Women have been doing rubber duck debugging for years. We discovered it last Tuesday while writing API error handlers. :)