How curious! I've been dabbling with code for over 30 years now and I've never heard of rubber duck debugging! However I do explain my code to my wife sometimes which often proves extremely useful as I either nudge myself into realisation by explaining it, or she says something that she assumes is just a silly idea (because in her words "I know nothing") but often ends up either being right or nudging me in the right direction.
Generally though (depending on the complexity of the problem) I tend to be able to hold the relevant context of a "running program" in my head and step through it as I read my code. It doesn't always work, and it's not always necessary as often writing tests to narrow down the problem is easier and quicker (and safer in the long run as it prevents regression).
If I really can't figure out a problem, I go right back to the very basics and take a pragmatic step-by-step approach to verify behaviour from the ground up until I hit a discrepancy, and then I can "zoom in" and repeat the process. This can be pretty time consuming though, so it's usually my last resort.