At a family dinner, speaking about being enrolled in the Flatiron School’s Software Engineer course, I ask what my idea for my first Ruby project should be. I get some amazing suggestions: online clothing size finder, city air pollution tool, and festival ticket price tracker. All great, but tricky to execute as an aspiring engineer. So, I put these on the bench and looked to something more achievable to get started on.
After some browsing, I was set on making a gem to collate holiday destinations in the UK and the attractions and accommodation in each. Being a Brit within my mostly American cohort has its challenges. So, I felt I should turn this into an impetus to build something.
As with any project, getting started is the hardest thing. I’m no stranger to code, but building something to a timeframe and not as a passion project was new for me. Despite this, I was very excited and eager so I dove right in; ready to get this done. The journey wasn’t easy, and was very much a Majora’s Mask-esque endeavour. Kinda wish I could just play the Song of Time and just repeat the three days it took to get it done. Unfortunately, time only goes one way. So here is how the journey went.
Day 1: stumbling out the block
As with anything I’ve worked on in the past, I just jump straight in and start pseudo-coding. As soon as I understand what I need to do, I can start building a solution. At this point, I understood my domain model of a place and activities belonging to said place. I understood how to create the instances with mass assignment using the send keyword within initialize method definitions. I understood how to isolate the data needed using Nokogiri and present it in readable form using method chaining. But, I didn’t understand why it took me 3–4 hours just to create my Git repo and set up the project directory so that I could commit changes.
In the past, I’ve built scripts with Python and a desktop application with Java 5. Being completely self-taught and working solo, I’ve never had to think about how I’m structuring what I’m writing. Everything I’ve written previously (save for some scripts) has been done with Google, a scrappy attitude and a boat-load of coffee.
This is definitely the first time I’ve written an entire project from start to finish without Googling solutions to my problems every 2 seconds. I wanted to rely as much as possible on what I had learned from the course and not sit on Stack Overflow for the entire project. The brief for the CLI project was not dissimilar to a Python script I had written to scrape data from an event’s website previously. But, creating objects from the scraped data and having these produce meaningful relationships was tricky and something I hadn’t done with code before. As such, this was the start of my first major road-block. My method for creating the different instances of the Place object wasn’t working and I couldn’t tell why. I removed the method definition and the code worked fine. I put it back in and it broke. I felt as though I tried everything to get the code to work and nothing was giving. Usually a quick Google gets me through roadblocks like this, but it was yielding nothing of note. I was beginning to despair and was exceptionally dejected at this point.
I had spent around 8–9 hours, non-stop working on the project (I have a bad habit of becoming hyper focused on completing tasks). I was nowhere close to finding a solution. So, I did what I always do when I reach an impasse with anything I’m doing: I do something else. I decided to start an entirely new project. The mission statement of this project was to monitor what the most played games on the Steam platform were using a site called Steam Charts. I created a new Git repo, created the project directory, and got the basics of the files done before calling it a day. Day 1 was rough and full of disappointment. But, I’m not one to give in easy. I learned a great deal about Git, VS Code, and Ruby. So, while far from a success, the day was not a waste. I come away and get ready to go again the whole day tomorrow.
Day 2: gaining speed
I wake up and get ready to start work. I’ve been wracking my brain for a solution for the roadblock I’m at with my scraping code. I figure that at this point, I have to ask someone for help. As I’m writing my Overflow question, I have a brain wave.
I realize the way I’ve been trying to use the method I’ve defined incorrectly. I wanted the Scraper class to create the data needed for the objects. In the code I had written it was being called as a class method, but it was defined as an instance method. I fix the problem and… Success, it works. After feeling very stupid I feel amazingly happy. I put the Steam Charts project on the bench and get moving on the original project.
For me coding has always been about overcoming these roadblocks. It motivates me to keep going; knowing that it’s not if I will be successful, it’s when. With renewed determination, I get to work on writing the code to create the Activity objects for each Place; using code to create the relationships between the objects. Up until this point, I hadn’t even looked at the CLI part of the brief. I was so focused on getting the scraping code done (remember my bad habit?) that I didn’t even think about how I was going to enter the program and use the data.
I had my pseudo-code, but that told me the what; not the how. I use the walk-through for the CLI project posted on learn.co to get an understanding of how I need to write the code for the CLI. The walk-through helps me get the entry point in the right place and start on the control flow of the CLI. I start using my pseudo-code to build out the functionality of the CLI. I roll on through getting the logic working and the data displaying in the right way. I get the pieces of functionality I want done, then hit a snag. My code to get access to the Place instance was not working and was causing the CLI to close despite the logic making it continue. While this snag was irritating, it didn’t demoralise me. I knew if I could overcome this hiccup, I only had to run through the video demo and the write the blog post. Despite my best efforts, I couldn’t find a way to fix the problem in this session. Knowing that I fixed a problem today that had me defeated yesterday I knew I could get this done. It’s not if I will be successful, it’s when.
Day 3: winner’s circle
Due to my day job getting on top of me, I had no time to work on the project until the weekend. Luckily, I had some solutions for my snag to try. The first thing I tried worked. I defined a method for the Activity class that let me find instances by their index in the Activity @@all collection. With some changes to the code in the CLI, I had a working control loop. The project was close to being done and I was ready to get it done. Having the project on my to do list for a week and not being able to do anything meaningful about it (the bad habit is still here) was aggravating to say the least. But, knowing that I could get everything done in time was motivation enough to stake out the time and get working. I fix an issue with the case sensitivity of some the Place instances’ names not working with the CLI correctly. Nothing method chaining couldn’t fix. I fix an issue with the control loop closing the program without an exit prompt and… that’s it. I’m done.
Where to start. The process was both amazing and stressful. I learned a tremendous amount about Ruby as a language. Being exceptionally functional and working very much like a human language makes complex processes and tasks easy to granulate and build, without having to sit in the documentation to understand how things work.
I’ve also learned that I need to become a Git wizard. One massive pain point for me in the project process was getting Git to work with me. I definitely have the fundamentals down now, but I need to get better at troubleshooting errors and using Git in terminal.
Finally, I’ve learned that being a Software Engineer is more than just a career. It’s a way of thinking: it’s not if you’ll be successful, it’s when.