Binding.Cry: Crashing Into My First Coding Hurdle
I started my software engineering bootcamp at Flatiron school with about 3 weeks experience in coding. I had been asked about joining a later cohort but was excited and wanted to start asap (small side note: I’d also been made redundant a few months prior and was quite bored. Also, the quicker I got started, the earlier I’d graduate, be able to secure a job and start earning money!). Some friends in tech advised me to play around with the basics for a few more weeks while others encouraged me to get started asap. The way I saw it, if you wanted to learn a new language one of the best ways is to move to the country where the language is primarily spoken. After 12 years in my previous career, I also relished the challenge of learning something new that was vital for day to day life and having such a transformative impact on businesses and life in general that only an insect under a rock could ignore.
To call my first week at Flatiron “intense” would be an understatement. Imagine being at an NBA game but when the t-shirt cannon is brought out, it isn’t rotated and fired into the crowd, it’s just repeatedly fired at you — yep, that was my first week. Once I started getting to grips with a topic, a new one would be introduced with an avalanche of labs. It felt insanely manic but the undeniable fact is that I was learning a great deal. By the end of the first day, I could easily fork, clone and navigate Git Hub (which I previously viewed as medieval Latin) and by the end of the first week, we’d covered object-oriented programming and had started on Inheritance. I couldn’t believe how much I’d learned and how much I was doing, unaided, in VS code so I forged ahead. With extra cups of coffee and reduced sleeping hours, I could get through this.
“It’s only 4 months, right?”
We all have seemingly insurmountable periods in our life that we eventually overcome. Who’d have thought that my first tough coding task to overcome would sound like it was named after an adhesive company.
On Day 1 of my course, my cohort were advised that we’d sit our first code challenge in 8 days. We’d also been advised that binding.pry will be important for the challenge. I’d briefly covered binding.pry in the pre-work but didn’t understand it. In the melee of week 1, I had it earmarked as one of the topics to research further but never spent enough time to get the hang of it. By the second week, I understood the basics but felt that solidifying my knowledge on object-oriented relationships would be more pertinent to the challenge than trying to master something I couldn’t grasp, in a short period.
How wrong I was.
I’ll spare you the details of my anguish, sorrow and disappointment but to put it succinctly, I failed my first coding challenge. The challenge was based on object-oriented relationships. After going through the readme, I decided on the joint class and built my seed data. I saw the “require, ‘pry’” and “binding.pry” winking at me on the console page but I ignored them as I typed in my seed data. I then went on to build each class and the initialize methods with the relevant attributes and arguments. I built the first bunch of methods with ease but as I delved into the challenge, the methods got trickier. I got stuck on a particular method and after about 15 mins, decided to try binding.pry. I copied and pasted the entire method into binding.pry (yep, “def” and “end” included) and obviously got an error. I tried lots of other things but nothing worked so instead of panicking, I decided to just carry on and keep typing methods in the hope that some would work when the challenge was reviewed. OO relationships are built from the ground up. If your earlier methods don’t work, just stop and figure out why. You can’t simply “forge ahead” blindly in the hope that something sticks because it likely won’t. What I did was like trying to build a house without a foundation. So, my house crumbled.
Binding.pry is an incredible debugging tool that assists you in building code in Ruby. It can test every aspect at a granular level and will confirm back to you, instantly, that what you’re writing works. It’s the mechanic that checks every element of your car is doing what it’s built to. Before binding.pry rears its head, you’ll be using IRB. IRB is invaluable and helpful to beginners who are getting to grips with Ruby but binding.pry is the sleeker counterpart with better features. You can type binding.pry directly into a method and it’ll pry apart the method and allow you to test attributes, iterations etc and highlights results in a variety of colours (yes, this sounds fluffy but trust me, after weeks of staring at the flat colours in IRB, you’ll be excited by the splash of colours in binding.pry).
I wouldn’t call myself a pry expert but now, a week after my challenge, I know a lot more than I did and would be able to pass the challenge. As I progress through the course, I know that I’ll build and expand on my coding knowledge and if the last two weeks are anything to go by, I’m confident that by the end of this 15 week process, dare I say it, I’ll be ready to be a developer.
