Failing my first (mock)code challenge
How using pry helped me overcome
Deciding to go to a coding bootcamp is not an easy decision to make. It’s more than just the monetary impact of paying for the course. It also takes committing 45+ hours a week to class, and even more to homework and studying. As excited as I was for the next chapter in my life, I was also terrified. My cohort and I had been drilling Ruby for a week and a half through virtual learning. We had reached our first mock code challenge, and I wish I could tell you I was prepared and totally nailed it, I’m sure if you read the title, you know exactly where this is going. I did horrendously, I didn’t even get to submit broken code, I barely submitted anything.
Where I went wrong
Throughout everything in the bootcamp so far, we had been supplied with tests that were easy to implement, which were useful, but also a crutch. Instead of learning when and how to implement my code, I would just keep on changing code until the tests passed, which although got me to write the proper code, it didn’t give the opportunity to learn why that was the proper code. After the hour and a half we got for the code challenge, I had gotten nowhere. The rest of the day was spent reviewing the code challenge, and although everything our lead instructor wrote down made perfect sense, implementing it was so daunting under the time pressure, without built in tests, and the fear of failure.
Helping Pry Help Me
The Ruby Gem pry was a game changer for me, but first I had to understand how and when to use it. Melissa Williams put it best when she said that pry is like IRB on steroids. Pry gives you better access to your code to know exactly what variables mean, and how it’s being implemented. Making your mistakes more obvious, and easier to fix.
All you need to do to get started is either run
“gem install pry” in terminal
or place “gem ‘pry’, ‘~> 0.13.1’ ” in your bundler
After you’ve got pry installed, you need to require it inside of any file you want to use it in, to do this just place “require ‘pry’ ” right at the top of the file.
Then you just need to place “binding.pry” anywhere inside of the method you want to take a snapshot in.
Once you run the file in terminal, you’ll be greeted with a pry session! This is assuming there are no errors, and you used the method the binding.pry is in.
Inside of the pry session, checking variables is as simple as typing it inside of the terminal, you can run other methods, even place a second binding pry somewhere after the first one to see how your code has changed from one step to the next. If you only have one binding.pry, exit will take you back to the terminal and finish running your code. If you have multiple binding.pry’s, exit will continue iterating through each pry until you reach the end of your code. If you want to skip the rest of your code, a triple bang (!!!) will stop running code and take you back to your terminal, and if you’re stuck in a loop, ^+C will essentially force quit the pry session and get you squared away, with some hints on what you need to do to fix your code.
My Next Attempt
After I had finally understood binding.pry, I was able to successfully test my code on the day of the code challenge. The difference was night and day for me. I not only finished on time, but even had time left over to optimize sections of my code. So the next time you’re frozen stuck in Ruby, try freezing your code.
