The Debugging Pen Pal: How Writing to an Imaginary Teammate Makes You Solve Hard Problems Faster

If you’ve ever spent hours staring at a stubborn bug or a confusing error message, you know the special kind of frustration that comes with being stuck. You add logs, you Google, you tweak things at random—and nothing moves.

What often breaks the deadlock isn’t a new tool or a smarter IDE. It’s something much simpler: explaining the problem out loud or in writing.

You might already know rubber duck debugging—the practice of explaining your code line by line to an inanimate object, like a duck on your desk. A surprisingly effective twist on this is what we’ll call the debugging pen pal: writing about your problem as if you’re sending a message to an imaginary teammate.

It sounds almost too simple. But regularly writing to this “pen pal” can surface hidden mistakes, speed up your debugging, and make you a sharper communicator.

Why Explaining Problems Works So Well

Before getting into the pen pal idea, it’s worth understanding why explanation itself is so powerful.

When you explain a problem in natural language, step by step, a few things happen:

You linearize your thinking.
Code and systems can be complex and branching. Writing forces you to flatten that complexity into a sequence: first this, then that, then this depends on that. As you build this narrative, contradictions and gaps become obvious.
You expose hidden assumptions.
In your head, it’s easy to gloss over things like “of course this function returns a list” or “this variable must be defined by now.” Writing them down makes you ask, Does it really? Often you discover that your assumption is exactly where the bug lives.
You slow down just enough.
When you’re frustrated, you tend to skim, guess, and jump around the code. Writing forces a small but important slowdown. That extra beat of attention is often all you need to spot a missing condition or off‑by‑one error.

The magic isn’t the audience. It’s the act of explanation itself.

From Rubber Duck to Debugging Pen Pal

Rubber duck debugging is based on this insight: when you explain a problem—even to an object that can’t respond—you often solve it yourself.

The debugging pen pal is a simple variation:

Instead of talking out loud to a duck, you write a message as if you’re sending it to a helpful but imaginary teammate.

Why does this help?

Writing is naturally more structured than talking.
You tend to organize ideas into sentences and paragraphs, which nudges you to clarify logic and details.
A “teammate” feels more real than an object.
Some people feel silly talking to a duck or a plant. Writing to a teammate—even an imaginary one—feels more like a normal work activity.
You automatically adopt a clearer communication style.
When you imagine another human reading your message, you put in more effort to be coherent, complete, and precise.

The result: you get all the benefits of rubber duck debugging, with an easier and more natural way to practice it.

How to Use a Debugging Pen Pal (Step by Step)

You don’t need anything special to start, just a place to write: a note-taking app, a scratch file, a private document, or even a physical notebook.

Here’s a simple process:

1. Start with context

Write as if your imaginary teammate has just joined the project and you need to get them up to speed.

What are you trying to do?
What does the feature or script supposedly do?
What does it actually do right now?

Example opening:

"Hey, I’m working on the generateReport endpoint. It’s supposed to accept a date range, query the database for matching records, and return a CSV file. Right now, the endpoint responds with a 200 but the CSV is empty."

2. Describe the expected vs. actual behavior

Spell out the difference in plain language.

Expected: “Given data between Jan 1–Jan 31, I should get a CSV with all matching rows.”
Actual: “I get a CSV with only headers and no rows.”

This often clarifies what exactly is wrong—and sometimes reveals that you’re testing the wrong thing.

3. Walk through the system step by step

Pretend your pen pal can’t see your code. You have to narrate what happens.

What functions run, in what order?
Which conditions must be true?
What data structures are used at each step?

Be explicit:

"First, the controller parses startDate and endDate from the query parameters. Then it calls ReportService.fetchData(start, end), which should return a list of records. Then CsvFormatter.toCsv(records) turns that list into a string. Finally, we send that string as the HTTP response."

As you write, you might notice something like: “Wait, did I validate the dates?” or “What happens if fetchData returns null?”

4. Note any assumptions you’re making

This is crucial. Whenever you catch yourself thinking “of course…” or “it must be…”, write it down.

Assumptions often look like:

“The input has already been validated.”
“This function always returns a non‑empty list.”
“The config is the same in dev and prod.”

Once written, assumptions can be tested or checked. Many bugs are simply assumptions that reality refuses to honor.

5. List what you’ve already tried

Your imaginary teammate doesn’t want you to repeat yourself, so write what you’ve already done.

Logs you added
Commands you ran
Experiments or code changes you tried

This stops you from running in circles and can highlight that you’ve only been poking at one narrow part of the problem.

6. Ask your pen pal a specific question

End your “letter” with a concrete question, like you would in a real message:

“Is there any reason fetchData might return an empty list even when records exist?”
“Could I be misunderstanding how CsvFormatter.toCsv handles null values?”
“Is there a better way to confirm the date range I’m sending actually matches the records in the DB?”

Often, by the time you formulate a precise question, the answer becomes obvious.

Why the Pen Pal Technique Works So Well

Let’s connect this back to the bigger ideas.

1. It exposes misunderstandings you didn’t know you had

When you’re stuck, it’s rarely because you know nothing. It’s because you know almost enough—but there’s a small misunderstanding somewhere.

Writing forces you to articulate:

What each part does
How the parts connect
What you believe is true at each step

Those beliefs get stress-tested just by being written down. You notice mismatches like:

“I said this always returns a list, but I also said it returns null on failure.”
“I claim the data is sorted, but I never actually sort it anywhere.”

2. It turns debugging into communication practice

Every debugging session becomes a little training ground for your explanation skills:

You get better at framing problems concisely.
You get better at highlighting relevant details and skipping noise.
You learn to ask clear, targeted questions.

Over time, this shows up in real interactions: better bug reports, clearer docs, and more effective messages to real teammates.

3. It’s easier to stick with than talking to objects

Some people embrace rubber ducks; others can’t quite get past how odd it feels.

Writing to a debugging pen pal feels more natural because:

It resembles actual work communication (Slack, email, tickets).
You can save, search, and revisit your “letters” later.
It requires no props—just a text box.

Because it feels less silly, you’re more likely to actually use the technique, especially when the problem is hard and your patience is thin.

Making It a Habit (And Reaping the Speed Boost)

The real power of the debugging pen pal comes from using it regularly, not just as a last resort.

A few practical tips:

Create a dedicated space.
Make a "debugging-pen-pal" document or folder where you keep these writeups. Over time, it becomes a personal knowledge base of past problems and solutions.
Use prompts.
If you’re not sure where to start, use a simple template:
- What I’m trying to do…
- What’s actually happening…
- What I think is going on…
- What I’ve tried so far…
- What I want help with is…
Timebox it.
When you feel stuck, spend just 10–15 minutes writing to your pen pal before you dive back into code. Often, that short pause is enough to unlock the problem.
Share selectively.
Sometimes your imaginary pen pal can become a real one. If your writeup is clear, you can paste it directly into a teammate chat or ticket. You’ve already done the hard work of explaining.

Developers who adopt this habit often find they:

Spend less time in vague confusion.
Ask better questions when they do need help.
Solve tough problems faster, with fewer random experiments.

Conclusion: Your Future Self Is the Pen Pal

The debugging pen pal might be imaginary, but the benefits are very real. By turning debugging into a communication exercise, you:

Force your thinking into a clear, logical structure.
Surface hidden assumptions and misunderstandings.
Practice explaining complex technical issues in simple language.
Reduce the time you spend stuck on hard problems.

In a sense, your pen pal is just your future self—the version of you who understands the problem clearly. Writing is how you bridge the gap between confusion and clarity.

Next time you’re stuck, open a blank document and start a letter:

“Hey, I’m working on this feature, and here’s what’s going on…”

You may be surprised how quickly your imaginary teammate helps you find the real bug.