As the horizon that marks the end of Module One at Turing nears, it's only natural to reflect upon my own learning journey so far. It is remarkable to see what was learned and applied in a number of weeks, considering I only had a murky comprehension of classes or variable scope on day one. And now, I'm working with a partner to build a database that utilizes an albeit arbitrarily compiled data set.
A habit I worked on sharpening during this module involved asking questions that are action oriented rather than open ended. It's analogous to asking "How do I want to live life and what is it that I'm willing to struggle for?", versus the hefty question of "What's the meaning of life?" Since Test/Dream Driven Development (T/DDD) is heavily emphasized, this specific post will use the context of tackling failure and error test messages to explain how my thought process has evolved since Day One at Turing.
Early on, my initial reaction was to simply stare blankly at the screen, space out at the mere sight of the words "Failure" or "Error", and then seek a translator via any willing good samaritan at school or the Internet. I soon became aware that there is a distinction between asking generally - "How do I figure this out?" - and asking specifically - "What is the return value?", "Is this the desired return value?", "Is this an error message or failure message?" and "What are the preceding steps and values that led me to this problem?". These guiding questions may seem obvious and logical, but I did not start getting into this habit until a few weeks into the program. This may be partly due to the inherent nature of being a complete newbie - you don't know what you don't know prior to being exposed to the fundamentals.
Regardless, we are fortunate to learn programming at a time when the following core tools are available for problem-solving:
(1) Excavation: Pry has become a close enough friend to whom I can turn as a helping hand for debugging or pure experimentation. It metaphorically functions like a pry bar. You can jam the pry bar anywhere by putting require 'pry' at the start of a program file and throw in binding.pry somewhere in the code where you suspect the execution issue occurs. When you require Pry, it hits the breakpoint (where the binding.pry is placed) and opens an interactive session in the terminal where you can call on methods and see their return values. From there, you can play until you encounter the undesired outcome. This will allow you to see exactly where the error or failure is occurring. Then you put on the other thinking cap and experiment with changes to rectify the situation. As the instructors say here, "Pry is free."
(2) Conceptual: The mega conceptual pillars I took away this module include understanding the Ruby object model, return values, and differences between incomprehensible syntax/code (often sources for error messages) and incorrect leverage of sequenced values (often a source for failure messages). Working on grasping themes related to these pillars certainly enhanced the level of intentionality I have exercised in the debugging process.
In short, utilizing these tools has made problem-solving feel more manageable and relatively less nebulous in my learning this module.
Breaking down logic is the name of the game and this game is not without helping aides!