Today is the day: I’m finally writing my first Flatiron Blog Post (cue balloons)!
Because the pace of the full-time program is accelerated, this is the first time in over two months (since receiving the prework) that I’ve taken a moment to stop and reflect on my progress. Thinking back to where I was a few short weeks ago, there is no way I would have believed that I’d be building a working gem app in such a short period of time. The program’s accelerated pace makes it difficult at times to look past the test suites towards how these concepts will ultimately build on each other, but on breaking from the Learn IDE earlier this week, I’ve been amazed at how quickly my mindset adapted to apply these tools to any number of diverse applictions and purposes.
By far the most important lesson I walked away with was how crucial it is to scope a concept appropriately. The core of my first project proposal (a song finder for J.S. Bach’s vocal music) not only had the potential to balloon into a sprawling mess of a CLI interface, but it also would have required a second level scrape upon initialization in order to function at the most basic level, which would have meant collecting information from over 250 webpages from the get-go. Luckily, I only spun my wheels for a day before bringing my concerns back to my coach, who agreed that it wasn’t the best fit for the project’s expectations.
Even once I settled on my final choice, a CLI search engine for the Criterion Collection’s film catalog, I had a rough two days getting my program off the ground because I was trying to build my most advanced search methods upfront. It wasn’t until I scaled back my focus in order to make sure the CLI would return a list of all the film titles, and from there allow the user to select an individual movie to view its profile, that I began to see where and how I could implement further methods in order to flesh out my program. Starting at the ground-level allowed me not only to concentrate my attention solely on each new element that I was building, but it also made my errors far easier to debug since I knew that each one was isolated to the specific portion of the code in front of me. As an added bonus, I found it far easier to construct new models and methods because I was able to identify similarities in their base functions and directly copy them into new objects, rather than trying to compare the higher-level functions of an entire pathway within my CLI.
Lesson learned: always scope outwards from the most basic function. I can’t begin to express how much more quickly my coding became once I took a step back and focused my attention. Refactoring can always happen down the line to increase your code’s efficiency, but if you don’t have the logic of your code expressed in a clear, explicit manner, it’s going to cause a whole lot of headache when things start to break down the line.