Througout our entire relationship with my now wife, I doubt she has even seen me as frusterated as she did when I was trying to piece together this final Ruby CLI project. While it is true that many times I stared at my computer screen trying to decide what would be the most fitting punishment for it not obeying my commands; I considered everything from dipping it in water, to pouring hot wax on the keyboard, to just running up to the roof of my apartment building to try my hand at the discus throw with this seemingly useless and stupid retangular piece of garbage.
But I digress.
From the very start of me learning how to code, one of the most appealing traits of coding itself is that you can make a program do anything you want, as long as you can effectivley communictate and tell the program EXACTLY what you want. A friend of mine who works in the industry told me a bout a revalation a kid had when he was teaching programming basics. “Computers aren’t smart. They are just dumb REALLY fast!” Wiser words were never said.
The project began with the nagging question: “Ok. so what am I going to do?” Being put in the driver’s to actually create something that I would have control over was intimidating. Every detail would be up to me. I had to start with figuring out what API to use; this would be the first monumental hurdle in my battle against rock-hard Ruby. Upon learning that there are endless APIs out there and that I could build almost anything and everything I did what most people do when they are faced with endless possibilities: I completley froze. It was only until the instructor in the video demo pulled information from a Pokemon API that I went “Well if he can work with Pokemon, I really can do anything!” I then proceeded to find an API based off of Yu-Gi-Oh! the trading card game that I played as a child and still collect cards to this day. The playing field was set, all I had to do was code, code, code.
Remember that frusteration I mentioned back up top? Turns out it’s all part of the process. I had to build out so many files and in those files so many methods before I could start running my code. Then all the errors poured in. Redo this, tweak that, a “binding.pry” here and an “unexpected end of input” there; I was slowly but surley making progress. I had to tell myself what exactly I wanted to do with the code, and then figure out how to put those plans into action and place my thoughts on the screen. My first cry of victory was heard when I successfully got the informaiton from the 20 cards I was pulling from the API. There was actual proof that what I had created was working. I could display the name of each card, what type it was, and what sets the card was printed in throughout the history of the game. The adrenaline of success kicked in, and I delved deeper into my code. At this rate, I would be finished in no time.
Or so I thought.
Fast-forward to me proudly showing off my project to my instructor waiting to hear something along the lines of “Wow, this looks great!” or “I really like what you’ve done here.” Instead I founs out that not only was my project incomplete, but I had quite a long way to go. Crushed and devastated, I once again went “back to the old drawing board” as Marvin Martian would put it.
One weekend and two extremely long and hard evening coding session after a long day working brunch and I have tasted sweet, sweet victory (at least I hope). It came down to me understanding the different parts of my code, and which could run independantly of oneanother. From there I broke some bigger methods into smaller methods and rearranged the order in which they were called, focusing on clear and concise methods, that resulted in displaying clean information to the user.
My main takeaway from this was persistance. It was knowing that the correct answer existed and was possible get right, providing I could focus hard enough to get there.