Rubber ducking is a software development technique in which you communicate some problem you’re dealing with in an attempt to gain better clarity or understanding of the problem. The communication can be verbal or written, and the audience can be real or imaginary. In this article, I give you some tips for facilitating a recurring rubber ducking meeting with your team.
Inspiration for this Article
In late 2021, our team decided the daily standups were taking too long. If you don’t know, a daily standup is an Agile ceremony consisting of each member briefly stating what they worked on the day before, what they’ll be working on today, and anything that’s blocking them from getting their work done. Any necessary subsequent conversations are supposed to take place offline.
Our team was was doing great except when it came time to talk about blockers. We would have full-blown conversations, taking deep dives into the code, and often solving the problem for the developer that was stuck.
This was great and everything, but our team consisted of two backend developers, two frontend developers, a tester, and a product owner. Often, only one or two people were interested in the troubleshooting or could even contribute to figuring the problem out. Also, standup isn’t the time for debugging, so we decided to make a concerted effort to keep our standups on task.
However, as a newcomer to the company, I was learning so much from these deep dive sessions; they were instrumental in building familiarity with the codebase, learning how the company “did things”, and picking up new debugging and troubleshooting techniques. I didn’t want to miss out on these invaluable learning sessions, so I proposed a new weekly meeting: the team Rubber Ducking session.
The team rubber ducking session was an instant hit and is still going on 8 months later with no indication of stopping. The rest of this article will talk about some things we learned about making these sessions helpful to everyone.
General Format
The format of a rubber ducking session is pretty simple. Everyone logs in digitally (or meets in a room if that’s your thing) and the facilitator asks if anyone has anything they’d like to rubber duck.
If someone has something, they bring it up. They start by explaining the problem they’re trying to solve, the general approach they’re taking, and why it’s not working. Example:
Facilitator: Does anyone have something they’d like to rubber duck with the team today?
Erik: Yes! I would like some help on this thing I’ve been fighting with.
F: Ok, Erik, go ahead.
E: Ok, so I’m trying to create a pruning feature in the database that copies some data into a table with a temporary name, deleting the original table, and then renaming the temporarily-named table to the original table’s name. I tried doing this by adding the functionality to a rake task, which seems like the right way to go. But my problem is that some of the DDL statements can’t be rolled back in case of an error, I’m not sure what to do.
At this point, I (Erik) would share my screen so everyone can see my code. Then, I ask everyone else if they have any questions and listen to any ideas they might have. In many cases, we’ll start implementing changes right away.
After a while, either the problem is solved, or there’s a pretty obvious path forward that I should run with later after the session. At that point, the facilitator asks if anyone else has anything. If so, you repeat the process. If not, the meeting ends and everyone gets goes back to what they were doing.
Improving Developer Productivity
It seems pretty simple right off the bat, but don’t let that make you think it’s not an incredibly helpful meeting. One obvious way these meetings improve developer productivity is by getting someone unstuck on whatever problem they’re working on.
Another way rubber ducking sessions help with developer productivity is by exposing developers to parts of the code they’re not yet familiar with. This knowledge sharing helps developers see the bigger picture of a codebase and the current sprint. It’s also helpful to watch people fix problems in case you end up confronting a similar problem later; you’ve already seen how to fix it!
Detailed Description of a Rubber Ducking Session
Here’s how a typical rubber ducking session might work in real life. Say our meeting is scheduled for 1pm, right after lunch. I have a problem I’ve been struggling with and want to show the whole team.
I go to the meeting room or log into the zoom/google meeting/teams/whatever. The facilitator asks if anyone wants to rubber duck anything. No one says anything, so I bring up my problem.
I give a quick synopsis of what I’m trying to do and why. Then, I will say what I’ve tried to do so far and talk about what is failing. I will give my own opinions about why my approach isn’t working, but then I’ll let someone else give their opinions.
In many cases, another developer will speak up, asking if they can see this file or that, ask a few questions, and so on. As you collectively explore the problem, at some point, someone will say something that clicks for you. Either they’ve seen a similar problem or they frame the problem in a way that you hadn’t thought about before.
At this point, the rubber ducking session is over for you. You’ve gotten beyond your main roadblock and either have an answer or a new thing to try. It’s time to give someone else the chance to present their problems so the team (and you!) can help them through it.
Dos and Don’ts of Rubber Ducking
If you do decide to introduce a recurring rubber ducking meeting in your org, you should do it in whatever way works best for your team. Having said that though, there are some things I learned about facilitating this meeting that I think are probably universal:
Do invite QA, designers, and product owners. In my experience, people on these teams are interested to see what you do and they can add nuanced opinions that you wouldn’t get from a room full of developers.
Do make the session the same time every week but don’t make the meeting mandatory. The meeting should happen on a schedule, but attendees should be free to come and go as their work permits. This should not be a mandatory meeting!
Do invite people from other teams but don’t prioritize their problems over your own team’s. When we started this, a few developers from unrelated teams asked if they could join. You should let them because it’s nice to have ideas from people with different experiences. However, you must prioritize your team’s issues over another’s.
Do invite staff-level developers or architects. Whatever you call them, the developers in your organization whose knowledge and responsibility transcends a single team. If you can get them to fit your rubber ducking session into their busy schedules, your team will benefit immensely.
Don’t let the meeting get too big. I recently learned that a similar meeting used to be commonplace in the company, but the list of attendees included more than 50 people. I think it’s important for the rubber ducking session to be somewhat of a little personal and informal. With more than 50 attendees, it’s likely many of them aren’t paying attention or are wasting their time by attending.
Room for Improvement?
Like I mentioned earlier, each team will require a slightly unique approach to the rubber ducking session. You’re more than welcome to use my description as a general framework, and I invite you to let me know what you’ve tried. Tell me your own dos and don’ts, your own experiences. Let’s learn from each other!