You may be familiar with the term rubber duck debugging. This is the idea that in order to help a programmer solve a problem, s/he should explain it to some kind of inanimate object (most commonly a rubber duck), because in the process of explaining the problem they will often solve the problem.

I'm finding that the best way to help people with their problems is to become that rubber duck. Though, perhaps, a slightly smaller one.


Image is Rubber Duck, found on Wikimedia and used under license.

Becoming a rubber duck is not terribly difficult, though it does take some practice. Here's how it works: you listen to your coworker's problem. That's it. Don't offer opinions, don't espouse your favorite Javascript framework, just shut your mouth and pay attention. Much of the time, they will solve the problem through the mere act of explaining it to someone else.

The key is this: if you do this for enough people, eventually you get recognized as "the guy who helped me solve my problems". Which is wrong, of course; you didn't actually help, they just talked through their problem enough to work it out for themselves. You weren't any help to them at all.

Or were you?

Listening to other people describe their problem is the fastest way to solve that problem. The simple fact is that the other person already knows more about this particular issue than you do, and so s/he's infinitely more likely to solve it before you even understand what precisely is going on. You simply aren't going to grasp all the nuances of that precise situation as quickly as they will, because they have spent time in the trenches and has seen more than you have. If you're the kind of person that needs to know everything (like me), part of becoming an effective rubber duck is letting go of the idea that you know everything you need to know, because you don't and you never will.

Even if you actually do know the answer, sometimes you need to let your teammate solve it for themselves. Particularly when you are in a mentor/learner situation (as I am with my junior devs), it becomes essential to allow the junior team members to work out issues for themselves and not just their solve problems for them. Doing so merely teaches them that you are the solution, when what you actually want is to show them that they can find the solution.

Becoming a rubber duck also helps to craft the image I mentioned earlier, of "the guy that helped me solve my code problems." People are very often not looking for help, they are looking for a solution. How they reach said solution is irrelevant. If you help them reach the solution they are looking for, even by saying nothing, they will remember and let other people know.

Listening is a skill. It takes practice, particularly for individuals like me who are easily distracted and would much rather be solving problems of our own. But it's now a core part of my job as a lead developer. I cannot do my job correctly without listening effectively.

Work on your listening skills. Software development is a team sport. We're all in this together, and we all succeed or fail together. You aren't going to succeed if you can't listen well. Offer opinions or suggestions if they're truly relevant, but otherwise if a person comes to you and asks to explain their problem, don't talk. It's counter-intuitive, but the person who listens the most often becomes recognized as the person who solves other people's problems, and you want to be that person.

Become your team's rubber duck, and just listen for a bit. You might find that you solve more problems by listening than by speaking.

Happy Coding Listening!