It Takes a Village

Here I am, around one month in and blogging about my first project. I remember the first blog I wrote. I was two weeks in and felt like my head was below water. Fast forward to now and I am submitting my first project. Wild to think how quick time has flown. This project was taking the lessons I have worked on for the last month and put it to use.
The process was way more different than anything I would have worked on pre-pandemic. This process was slow to start but began to snowball once I was able to conceptualise my idea and put it into practice. I wanted to touch on a couple techniques I was able to use to make this all come together but I would be dishonest if I didn’t address the most important technique I used to complete this project.
All the lessons I have worked tirelessly on were very useful but they paled in comparison to the support structure I had to work on this. I know in a perfect world, being a loner and crushing this project with no help would showcase my coding ability but my experience was much different. I felt lost and overwhelmed but talking to another classmate who was in my same boat, I used the proverb “How do you eat an elephant? One bite at a time.” I didn’t realise it at the time but my elephant was going to be a shared feast, not a dinner for one. My project was designed by my hands but the ideas didn’t come from just me. Some contributors actively helped me by peeking at my code and giving recommendations. Others were passive contributors. Those people went to open office hours and explained their problems and had experts give feedback. Like any good musician who has writer’s block, I attended these meetings for creative inspiration the same way a musician listens to other artists at a local venue. This has always been customary for musicians for as long as the profession exists. Why would coding be any different? This is an art and a science wrapped up into one. I also had experts look at my code and give me pointers. Without this support structure, I may not have had a working project like I have now . This project may have been my baby but it takes a village to raise a kid. My code may have needed some extra eyes but at it’s core, certain techniques had to be used to achieve my application’s goal.
The application’s goal is to take in API data and parse through the raw data to display the designated data to the user. I had worked in bars for close to the last decade. I chose an API that holds recipes for cocktails. I wanted to design a file that would create a new instance from the users input and display the drinks information from that API. My command line interface (CLI for short) would take in the user input, run it though a API file, gather the data, then run it though my Operator class file to extract my designated data. The use of if/else statements was used to syphon the invalid user input and return them to the search. In order to display the pertinent information, I had to iterate though data stored in a hash and convert it into an array. From there, I used the Operator class to store the selected cocktail with a class array. I will use this data to display their bill when they ask to see their bill or settle up. The use of if/else was then changed to a case statement when/else. Using a gem to help me clean up my typos and sloppy format, I discovered when I write “If user_input == 1” is the exact same thing as writing when 1 do local variable. This made my code look professional and showed me how I can write what I want much more elegantly.
One of the other concepts that I had to grasp was the ability to tap into local methods to clean up my code. My application started with a giant 30-something line code that could easily break if one thing went wrong. Instead of allowing that to exist, I broke up each of it’s functions to have it’s own use. I think of the word compartmentalisation. If each local method had a specific function, I would be able to debug much easier and expand my application’s functionality. That 30 lines of code may have grown to 70–80 but each method did not have dependancy on one another unless i designated it. This made me look at some of the code I wrote in the past and made me realise a lot of the headaches I suffered were because I was so focused on one method working for all instances, I made a method that was too important. By writing new smaller methods, I was able to design a foundation that would enable another user or myself to expand on it. Very similar to a good foundation for any building. If built correctly, it would enable a builder to design a building that could be three stories tall or one that was fifteen stories.
Overall, my experience with this project gave me perspective on what my professional career will look like. The probability of me writing applications in a dark room by myself sounds more fictitious than the reality of me working in projects in an environment where others can contribute and give feedback. I by no means feel like an expert after this project, but this gave me a real-life experience of the phrase “It takes a village” when designing an application.