We have all been in this situation at some point: we are preparing to work on a feature or a complex bug. We are not familiar with the code around us or we are simply facing a more complex situation than we imagined. For this, we usually ask a partner for help and we usually do a teamwork session with the partner synchronously. We have started a “pair programming” session.
By starting this process of communication and explaining the situation, it often helps us understand the problem in a better way. In The Pragmatic Programmer, written by Dave Thomas, for the first time I read the term “Rubber Duck Debugging”, which is based on explaining to a rubber duck the problem you are trying to solve, line by line, in order to fully understand the background of the situation.
This method is based on the Feynman learning technique, which could be summarized with the phrase “if you want to learn something, you must be able to teach it to a small child.”
Many times, just by starting the process of explaining it, we find the solution to said situation. I’ve been through this hundreds of times with my friend and colleague, Leonardo Moreno Jr.: we get on a call, I explain a situation to him and after 2 minutes I tell him “I think I know what it is, I’ll call you in a few minutes.”
And sometimes, the problem is simpler than we imagine; sometimes the solution is in front of us, sometimes even the partner gives us a totally different and new perspective.
We engineers tend to be stubborn, stubborn or even intransigent. However, sometimes it is good to ask for help, even if it is from the “rubber duck”.
In contrast, partner work sessions can sometimes be tiresome, they can rob us of energy or even distract us from the real objective. To do this, I have some notes that I find useful when we try to start this process:
- Do it with colleagues with whom you feel comfortable and trust. If you don’t feel comfortable, it’s going to be very difficult - as there may be questions that you consider “dumb.”
- This is a process that must be natural. I don’t think it should be mandatory, and making it mandatory eliminates the sense of “collaboration.”
*Not all code actually requires pair programming. Starting a session to analyze a response from an extremely huge server is going to drain both engineers.
- Try to make sessions quick, concise and to the point. If you think the session is going to last a long time, you can separate it into mini-sessions of 20 minutes maximum. Respect other people’s time.
- Have a list of things you have tried and how far your previous research went. If you can have a list of specific questions, it is ideal.
- Don’t take anything personally. Remain open to comments, criticism and questions. Maybe the other engineer doesn’t know the context as well as you, but he has every intention of being there with you.