I seldom typing code in front of people, and when I do, the code quality degrade massively. Most of the time, the code just don’t work or have an obvious bug. I can’t even debug when there’s people around me. Many people always ask me why, because when I’m alone, I tend to write an okay-code: a code that works. So why?
Because most of the time when I’m coding, I use what people call Rubber Duck Debugging, and I’m addicted to it, so I can’t code well when I’m not doing it. So what is this rubber duck debugging? It’s a technique where we do debugging while eating a rubber duck. *AHEM* Okay, seriously. It’s a technique of debugging where while debugging, a programmer read the code, line by line, aloud, to something. And because a great software developer loves rubber duck, that “something” is a rubber duck. Hence, the name.
What’s so special in rubber duck debugging, aside from it makes people think you’re a freak? It forces you to think, to explain your code line by line to the duck, because you know if you’re doing something wrong – some silly, deadly, sinful code – the duck will turn into a raptor and eats you. I don’t use a rubber duck by the way, I use a pencil, a pen, or whatever item within my reach. It’s a great way to debug, and it helps me more that Visual Studio or Eclipse ever did. I’ve done programming this way since I’m a kid and I’m also forced to do it when teaching, so I can’t just leave the habit. But it’s a great alternative way to debug when your IDE can’t help you. Trust me.
Another reason why I’m not so good when people surrounds me is I can’t get my mind to work when I’m not in trance. More on that in the next post. Meanwhile, happy debugging 🙂