Don't Forget the Rubber Duck

As someone who didn't come into software engineering from a traditional path, it was way down the line before I first heard the term "Rubber Duck Development." Everyone else out there probably knows full well what I'm talking about already, and there's really not that much more I can say about the core principle. I will do so anyway - in short, it describes a simple trick of the human brain: when trying to work through a problem, talking about it can unlock new perspectives that can then unlock new and better methods to solve the problem itself. This is clearly applicable to solving logical problems of the types that software engineers face constantly, but the idea holds true for working through any kind of problem without a clear solution. Talking about it makes it easier, to the extent that sometimes you needn't get a response from your conversational partner at all; in fact, the name for the phenomenon originates from an engineer talking to an inanimate object and not a colleague.

As someone who works remotely, I find that it can be easy to forget the rubber duck. Being alone in an office all day and not one particularly given to talking to myself, I find that it can be hard sometimes to not fall into a gap in my thought process which precludes the rubber duck situation. Sometimes this is okay - sometimes a problem's solution is straightforward and leaps right out at me. Other things, though, require that duck. It's very easy to find a path and follow it for a day or two and suddenly realize that you've missed something big and have to backtrack, especially in projects where you're not quite as familiar with the paths to begin with. When you're physically isolated, just like if you were hiking that path on your own, sometimes it's hard to see anything other than the end of the path in front of you until it's too late and you've missed out on an opportunity.

Today I'm thinking about pulling together data from various sources that can be combined into a cohesive visual report (as usual, I'm speaking as generally as possible because it's proprietary data I'm collating). The sources don't all provide the same metadata by default, so it requires some significant mental processing to determine what data is similar across all sources but still unique enough to create segmentation of the reporting. I spent a fair amount of time in my own head thinking I had a solution, because it was the first solution that came to mind - it took some rubber ducking to realize that I didn't have sufficient control over that solution to establish confidence that the segments would be accurate. It then took a second round with another person to realize that the confident solution already partially existed and could be extended to do what I needed. I burned the better part of a day doing the wrong thing, and was able to get myself back on track within an hour just by looking outside the few square feet that is my own workspace, and then was kicking myself for not doing it sooner - this both despite and exacerbated by the fact that I thought I was on the right track all along for that time.

I've never been one for peer programming. Again, maybe it's my background and how I became a developer in the first place, but I've always personally found it to have negatives outweigh the positives, particularly in terms of efficiency. I prefer peer review after initial development to having more than one engineer developing simultaneously together. But rubber ducks are the one place where I feel comfortable backtracking on that, because they're ad hoc and happen during times where development is at a lull anyway. The upside to getting a rubber duck for a few minutes can be huge, whether it's a person or an actual duck on your desk, especially if you're otherwise stuck in your own head due to proximity or preference. If you can train yourself to not forget the rubber duck, even when you're not feeling stuck, you'll get more and better work done regardless of the project.