Learn-co: Debugging with Avi

Blogging gives me the opportunity to clear my brain. Sometimes it feels like my head collects too many thoughts at once, and if I don't release them someway somehow, my mind gets really foggy. I have a hard time concentrating on other things when that happens, hence this blog post! Or sometimes this surfaces in other forms of creative outlets. 

This post will seem out of order to my previous posts, but that's because it is. After RubyConf, instead of blogging my recap, I spent the rest of my time traveling. I didn't get to my destination until 2:30 this morning! Don't worry, I will write two more blogs to wrap up my RubyConf2015 experience. One will be a Day#3 recap, and the other will be about the Opportunity Scholar Program. So for now, bare with me while we talk about a live stream I just attended! 

Rubber_duck_assisting_with_debugging.jpg

The web conference was hosted by Avi from Learn-co (a fantastic teacher!), and he used a live example of the code we wrote for tic-tac-toe to walk us through the debugging process. Error messages are scary at first, but we really need to think about them as huge favors because they are telling us HEY, THERE'S A PROBLEM! And with a little more understanding you'll figure out that it also says, DON'T FREAK OUT, I'M HERE TO HELP! MAYBE YOU SHOULD LOOK HERE, AT LINE X, OR START HERE AND DIG DEEPER! Repeat after me, error messages are our friends :) Instead of using profanities, you should be saying, thanks for the hints! 

The format of this session reminded me a bit of google hangouts, where you can see the other people (students) talking and you can also see the share screen of the administrator. To be honest, I was NOT ready for that, so I turned off my camera and audio. But next time I'll be prepared and join in from a more appropriate setting. It was hosted by Ring Central and as students, if you can't attend a session, they are recorded which is great! 

As always I'll try to be concise, so the following are simply bullet points of what I learned/liked: 

  • Read your tests and errors, otherwise you will waste a lot of time trying to figure things out from scratch. Get into the habit of opening up the test files and reading them, even if you don't know how to write RSPEC tests yet. The more code you read, the more you will understand. Programming and debugging is similar to a surgeon using a scalpel; it needs to be precise and effective. Do not start from line one of your code and try to cherry pick your way through a problem. 
  • The "rspec --fail-fast" command in your terminal is your friend. It will allow you to deal with one error code at a time. 
  • Familiarize yourself with error messages. "Stack level too deep" suggests that there is an infinite loop. 
  • Be specific - Avi put a binding.pry in the code and was given an error message because it wasn't required in the file. When he asked us why it wasn't working, a student responded with the correct idea, but suggested to put "require 'pry'" at the top of the "page", not "file". Avi quickly corrected him and told us to be as specific as possible when we talk about our work for two reasons: 1) When we go to job interviews and call an item by its incorrect name, it may suggest that we don't know what we're talking about. Use the right language, call things by their proper name, and sound like a developer. 2) When we're forced to be specific, such as "local variable, 'board'", or "an array with nine elements, all of which are empty strings", we will force our brain to understand our own code better. 
  • Have expectations - make a guess about how something might work before confirming it (with pry for example). Does your guess match your expectation? Yes? Great, you just reconfirmed your learning (assimilated knowledge). No, it doesn't? That's OK, you're also helping out your learning experience (accommodated knowledge). Now go forth and fix it! The moment whether you figure out if your assumption is correct/incorrect is the moment you will learn. 
  • Do not worry about making code pretty while you are debugging. Make it work, make it right, make it fast. 
  • When he suggests a book to read, he corrects himself and says "If you are doing anything other than programming right now, you are doing it wrong." = stay focused/dedicated during your spare time. There's a lot to learn!

So on that note, I'm signing off to do some lessons! But before I go, if you want more tips you should check out his ruby debugging checklist on github!

My head already feels so much lighter :)