Rubber Duck Debugging

David Lago
4 min readAug 1, 2018

Rubber ducking, an experience I have forced myself to go through countless times when I was thinking about joining the Flatiron School boot camp. Never knew there was a word to describe what I do on a daily basis. I spent almost a year trying to understand the basics and some of the advance stuff of JavaScript. I struggled of course, finding out that JavaScript can be very difficult. I was always looking for definitions to help solve some of my problems, trying to figure out ‘what does what’, then trying to write it out on paper for myself. It was truly difficult. Deli Counter lab. When I first saw the questions it was asking for I was like:

I was stuck. I Kept drawing a blank. I then started questioning myself “Am I good enough for this school? Am I ready? What if I embarrass myself trying to explain my code to the interviewer.” In my head I imagined Lemongrab from adventure time be the interviewer and react with the line “This is… UNACCEPTABLE!!”

Then it hit me; I have to explain my code out loud! Line by line. I should start practicing explaining my code to my friends! So after I finished the last lab of the interview build up I ended up with this as my answer!

The first function “takeANumber” takes in two arguments, using one of the arguments as being the line itself, with having the customer argument be the customer, I used the .push to insert my customers onto the line. Then I returned a phrase which had each customer name and there position in line!

Then with “nowServing” I had create and if/else statement. If I had the line’s length equal 0, then I would have the phrase “There is nobody waiting to be served!” however, if there was somebody on line, I would have the else return the phrase “Currently serving” the current customer on line and then removing them once they were called.

The final one was pretty difficult. The function “currentLine” will return “The line is currently empty.” if the line is empty. Now for the else. I had to create a variable “loop” and then assign it to an empty array. Then I created a for loop which had an index start at 0, then compare it to the line length, then finally having it add upon itself, meaning “next on line”. Once the loop runs, the return would be “The line is currently” the next person in the array and made created a join with a comma, to put a comma after each name was called, all within the else statement.

I had to come to a study session to help complete this lab, huge shout out to the students! But now here’s the challenge… HOW AM I GOING TO EXPLAIN THIS TO MY NON PROGRAMMING FRIENDS! What they see is a bunch of random characters that make no sense and then they’ll be like “yeah! I get it! Good job!” (note: they didn’t understand) none the less it helped!

Looking at my code now while learning ruby, it looks a little weird right now! But the best way to approach this would be to explain it to someone! Explaining your code really, REALLY helps out! No matter who it is, or what it is… let me explain. “Rubber ducking is a method of debugging code, a programmer would tell his rubber duck line by line of code.” I tried it myself, spoke like a crazy person to an inanimate object but it really did help! This really helps me out when debugging code with pry recently, I will whisper to myself on what’s going on, basically being my own partner, it’s improved my debugging skills in ruby! From argument errors to using the wrong method. Every time I solved a problem, even the most simple to the most complex, I have a little celebration within me, looks a lot like this:

If you haven’t already tried this, I really recommend it. You’ll see some really awesome results.

--

--