New Fresh Pair of Eyes

There are many manuals and tutorials around about this “phenomenon”: Rubber Duck Debugging. Don’t worry, this is not gonna be another one.

A few words about it just in case you don’t know what I’m talking about..

Rubber Duck Debugging (RDD) is a debugging method that doesn’t have anything to do with technology, it works on psychology.
In RDD what you do is that you grab a Rubber Duck (yes, those that you take to do a bath) and explain it what the code does. What?! Yes!
That’s it, that’s the whole manual.

Why does it work? No one knows, it’s one of those mysteries of programming…

Just kidding, while explaining the RD what your code does, you are actually letting another pair of eyes go through your code, you are explaining to it parts that you mostly don’t go through twice. You don’t see function by function but you follow the code’s logical path.By saying “another pair of eyes” I don’t mean the rubber duck’s eyes (oh you! It’s made of rubber!), I mean your eyes but from another point of view. That’s what’s interesting about this method, and that’s what I want to talk about today.

I find myself using this method quite a lot. Not with a rubber duck, but with a colleague (we don’t have a budget for rubber ducks). I tried with other stuff on my desk, it also works, but the best results come from a colleague.

“When I find myself in times of trouble Mother Mary comes to me”

There are times you just stare at your code and don’t understand why isn’t it doing what I want it to do. You followed all the right manuals, did all your copy-paste from stack overflow, but it still doesn’t do what you meant it to do.

In those times, I try to get a colleague in my team and explain to him what the code does. Most of the time s/he asks questions and those lead to other questions and so on. The majority of the time it takes about 10 minutes for me to understand where my mistake is. That’s how powerful RDD is.

This brings me to XP. eXtreme Programming is a method where two programmers work together. One is the Driver, the one who has the keyboard and types the code. The other one is the navigator, the one that tells the Driver “where to go”. I have mixed feelings about this method. On the one hand, two brains work better than one. You have two programmers that work together and write one piece of code. I’ve seen studies showing that when working in XP there are fewer bugs in production and the quality of the code itself is better.

On the other hand, I think it’s risky. It depends a lot on the programmers themselves. In one extreme, you can have a programmer that takes this time to do nothing while the other one does all the work. But even if both of the programmers work together, there is a risk where the most experienced programmer takes the wheel and the maps and goes on a  kind of Solo mission. Even if he doesn’t mean to do it, and he isn’t doing it on purpose, the other programmer might feel he is not contributing.

I strongly believe rubber duck debugging is a strong debugging method. Actually, the real strong debugging method I’m talking about talks about bringing new eyes to the code. Fresh eyes. Talk to your colleagues, explain to them what you are struggling with right now, even if they are not on your same team. Especially if they are not on your same team. Different teams have different methodologies and different ways of solving problems.

When was the last time you had a presentation about other projects in your company?

Lately I’m working on a cross-team project and I started it by going to the other teams and seeing what they are working on, how they are solving the problems. One of the teams was struggling trying to make a graph using JavaScript. As you probably remember, I’ve had my time with graphs and tables – I showed them my team’s grafana and was able to save them time and bugs.

New, fresh eyes ask questions that old, mature eyes sometimes forget to ask. Because “that’s how we’ve always done it”.

If you want to grow as a developer, try to find those places that cannot be touched and touch them. Ask the naive questions. Bring another fellow developer to ask you those naive questions. You can’t imagine how much you’ll learn.

Next time

In the next few blogs I will be writing along-side my dear DevOps friend. We’ll try to explain the whole developer-devops relationship in an interesting way. See you then!