Have you ever use a rubber duck or any other inanimate object to debug your code or solve a problem you can't just solve by looking at your code? Can you explain your experience?
I don't usually bookmark sites I like but this one will surely come in handy! Really great posts and tips! So you totally deserve to be the second one in my bookmarks after <a href="essaysupply.com/">college paper writing services</a> (yes, I am geek student :)). Thanks a lot!
����
Well, I've been doing this for so long I can't even set a date. Not only mentally, but also to a physical duck, a storm trooper figure, and a mug with my name .. go figure ..
When you have to articulate to explain your code, you change your mental state in a way you would need to understand the semantics, and not the structure you had of it, which in turn makes you approach it in a different way. Explain what every function (to a particular problem) does, and the params it receives, so you'll get a different view of it ..
Recently, we had the chance to be doing pair programming, or get some other guy to sit with you and read through your code with you, which is even better ..
I often try to be a rubber duck myself to developers who are more junior than me. Rather than giving them the answer to a question or the solution to a problem, I ask them questions and lead them towards the answer themselves.
I just "rubberducked" my slack-team the other day. Was taking a screenshot to remind them that if you're stuck in your javascript code you can just stuff a "debugger;" statement in there to have the chrome tools break when you need it to. And by explaining how it worked, I discovered the bug that made me put it in there in the first place. ;)
Yes. Sir ducksworth is quite useful. And definitely much smarterer than me.
Agree with Cliff Rowley! Same here - I wasn't aware of the Rubber Duck terminology (had to google it. So, thanks for asking this question).
Most of the times, when I am stuck somewhere in the code I explain each line to myself and so far this has been pretty effective. :)
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.
Rudolf Erasmus
When mentoring in a team that had a couple of junior Devs at a client, I bought all of us ducky's and said that before they ask a question they should try and explain it to their rubber ducky's first and it encouraged them to try on their own first before just asking a question. I found it very good to encourage the behaviour that I don't mind helping them but they must show me where they have tried. In most cases by just trying an approach and not overthinking it they were able to resolve the problem. More than anything it encouraged a way of approaching a problem that the team snapped up really quickly and by the time they asked a question they would have a lot better context about the problem they were trying to resolve. I definitively found it to be very valuable for the team and for myself.