3 ms·
This technique is also useful for software development, and is referred to as rubber duck debugging (https://en.wikipedia.org/wiki/Rubber_duck_debugging https:/
by Maakuth 10y ago
This technique is also useful for software development, and is referred to as rubber duck debugging (https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging). Verbalizing your problem lends you another point of view to your thinking and often allows you to discover the problem yourself.
- justonepost 10y agoI take notes when I deal with a hard bug or write a email I never send.
- Rovanion 10y agoI usually start making a Stack Overflow post and if the subject is general enough I'll end up posting it.
- djsumdog 10y agoI learned about that once when someone turned around, started explaining the bug, and during the explanation, realised what the issue was. He then said, "Thank you for being my rubber duck." "Your what?" "Look it up."
- Maakuth 10y agoIndeed :). The background of the term is said to be in some university, which had a rubber duck near the CS teacher rooms. It was mandatory there to first ask help from the rubber duck, before bothering the real teachers. According to the tale, more than half of the students left after talking to the duck.
- allannienhuis 10y agoWriting detailed commit notes can be useful in the same way. I have backed out of a commit during the write up more times than I would like to admit because I realized that I hadn't covered some edge case or I completely forgot about something (like the effect of the change on a report or other sub-system). Writing things out in a way that someone else can understand forces you to re-think through the task in different ways.
- bhntr3 10y agoPeople sometimes tease me for reviewing my own pull requests. But I am a big believer in roles. The reviewer role is different than the creator role. When I mentally switch, through the priming mechanism of my code review tool, I am often able to see the defects in my own design or code. I sometimes do the same thing with design docs or proposals by imagining myself as the person who has the most to lose by my proposal succeeding and then commenting on my doc from their perspective.
- macintux 10y agoI've read that adding the "BUGS" section to man pages in the early days of UNIX had a similar impact. The developers got so embarrassed by the content that they decided to fix the bugs instead.
- Drdrdrq 10y agoIt is similar with the product we are developing. When I need to explain to the user how some feature is used, I often end up redesigning said feature so that explaining should not be needed. Makes for a much better UX. :)
- Drdrdrq 10y agoI try to explain my motivation behind change in commit log and avoid technical details myself. But I have another checkpoint. I always diff the code and review it as if I had to show it to a reviewer. If I need to explain something, it should be made better.
- bleair 10y agoI'm certain the value here comes from changing your focus and mindset. If you switch to a mode of thinking of "I ned to give you (the rubber ducky) context and explain concepts so that you can see intention and reasons for this code chage/ bug behavior". This change of mindset allows you to view and reason about things better.