Remote work tip: Rubber ducking with a journal

What’s Rubber Ducking?

Have you heard of Rubber Ducking? The idea is that whenever you’re stuck working on some engineering task you ask one of your co-workers to sit down with you and just explain the situation to them. Even if they’re just sitting there listening, you’ll come up with a solution 8 out of 10 times.

Some people identified that the value of this “collaboration” is more in the fact that the stuck person explains their problem, rather than the other person giving useful advice. So someone said “wait a minute, I could just talk to a rubber duck and get the same positive effect”. And they tried it, and it turned out that this is often true. That’s how I like to think Rubber Ducking was invented.

Rubber Ducking 2.0

Now, I’m proposing to do some form of Rubber Ducking but with a journal instead of a rubber duck¹.

I’ve got a “rubber ducking” file in my notes system where I write down the questions I need to figure out when I’m debugging something or working on a new feature.

This sounds like the nerd version of “talking to myself”. But think of it this way–Rubber Ducking with a journal is like explaining what you’re doing to someone over a text-based medium such as IRC or Slack. There’s just a little less detail to your writing because you share the same brain with the person you write for.

Does it work?

However crazy it might seem at first, I found these “rubber ducking” journals remarkably effective. Another benefit is that they provide a good sync point to pick up something again after a short break or lunch, for example. Having a somewhat detailed journal really helps with replaying your mental state so you can continue where you left of.

For my journaling I mostly use a blend of conversational writing, bullet points, and shorthand. Here’s an actual example from a debugging session:

I’m seeing some requests to www.example.com in from the portal dev env that take a while to time out. As an interim fix I’ve added a route to /etc/hosts file inside the docker container that maps to localhost so they time out instantly. (TODO: Will need to investigate the root cause later.)

How can I set a platform.Feature to enabled (for use in a fixture, let’s say)?

• platform.features.get_feature does a look-up via business.platform_features. And that’s a set of platform.models.Feature objects.
• So how can we create a platform.Feature for a given business? Let’s spin up a Django shell and try to create a platform.Feature for the ACME fixture business:
  1. Grab the business
  2. Create a Feature
  3. Access the business and see if the nav bar gets updated
  4. (then turn this into a fixture)

This note might not really make sense to you. But like I said, it’s a mixture of shorthand and conversational style.

I’m also thinking about sharing these notes with my team. The notes are pretty verbose but they might be helpful for someone new to the team trying to figure out what’s going on. I found these journal files to be pretty search-friendly, too. There are lots of grepable keywords in them and I often go back and look things up after a weekend or so.

All in all this is definitely one of the weirder productivity techniques I use when I’m writing software. But I decided to write about it because I found it very helpful.

So, if you’re curious, please give it a shot and tell me how things went for you!