My personal version of rubber duck debugging involves writing an email to explain the problem. It helps solidify my understanding and usually generates new things to follow up on.
Writing for a child forces me to keep the words and concepts very, very simple, and to write in a style that builds up usage of the program from first principles. Writing for the grumpy old-timer is a practice in minimizing questions from them, forcing me to do a sort of final pass on the overall design of what I'm writing about, to defend design choices, and to add future improvements to the backlog. Drafting the documentation for semi-finished features that are still in progress has sometimes led me to change the design in order to make writing the docs targeting these two people simpler.
Then I'll have this odd memory of - "I discussed this with you, I told you all abo- oh wait, I didn't send it."
I felt I was wasting too much time. But I've realized that for me the time spent writing something in details has always helped me fill in the gaps and also discover the unknowns.
When writing a StackExchange post asking for help, I want to include all relevant information and include a list of things I've tried, along with explanations for why they're dead ends.
Writing it all down sometimes helps me realise that one of the ends is in fact not dead.
Rubber ducking can be a highly productive measure when your mentally clouded and can take many forms.
I'm using Obsidian right now for this, although you can just use plain code editor it's nice to have WYSIWYG.