Module 2 of the immersive software engineering program at the Flatiron School is reputed to be the most difficult, at least that's the word on the street here at the Denver campus. Viewing it successfully from the rearview, I can confirm. We will no doubt deal with more advanced topics in future mods, but what made Mod 2 so difficult was the sheer volume of new concepts that you had to learn in the short march up to project week. Drinking from a firehose indeed.
However, it was during the project week of Mod 2 that I began to feel like a real developer. It was also during Mod 2 that I learned about the unique challenges, and value of working with others to create a full stack web application from scratch. One of the things that initially drew me to programming in the first place, is my love of creating things. I write poetry and draw in my spare time, and there are few endeavors that I enjoy more than seeing something brought into the world that I created.
For me, writing, drawing and coding have been primarily solitary activities. Yes, I had pair programmed during my Mod 1 project, but for that project my partner and I kind of both did our own thing, and only really talked when it came time to push our code up to GitHub. Maybe it was because we had a group of three people instead of two, but my partners and I really came together and worked as a team to see our project through to the end. The fact that we were able to achieve this completely remotely, due to the fact that we are all quarantined because of COVID-19, is a true testament to what people can achieve with excellent communication and a desire to do the best possible work that they can.
That first morning, we all hopped on a Zoom call to brainstorm ideas about what kind of application we wanted to build. The tricky thing about project week at Flatiron School, is that you have to find just the right balance between ambition and what you can reasonably expect to finish in the time allotted. Having no initial clue as to what we wanted to build, we all agreed that we at least wanted to get practice using an API instead of seeding our own data.
Next came the task of sifting through all of the free APIs out there. We finally decided that we wanted to make a watchlist app where the user can make a list of HBO shows that they want to watch, and also a list of HBO shows that they have already seen. It turns out that there are a number of free television APIs out there, but it also turns out that they are huge in size, and a little intimidating to a group of fledgling developers like ourselves. One we looked at had over 40,000 entries and no real way to isolate just the HBO shows. Even though we spent the greater part of our morning trying to do just that.
Having hit our first snag, our Zoom call fell into an awkward silence. I continued to peruse the APIs and came across a lovely little API that listed all of the pertinent information about the films of Studio Ghibli. The data looked good, so I pitched the idea to my teammates. It turns out that everyone loves Studio Ghibli, and the good news was that we could easily adapt the API to fit with our current project idea.
We continued our Zoom call and proceeded to draw out or backend table migrations by hand. After having successfully fetched the data from the API, I proceeded to code the backend of our app using Ruby on Rails. Since I was sharing my screen with my teammates the whole time, whenever I got stuck they were right there to help me. Also, one of the other things I love about pair programming is that your partner, or partners in this case, help you catch syntax errors, and are always ready to bounce ideas off of when you get stuck. It really expedites and optimizes the programming process. I see now why it is such a widely utilized practice in our industry.
Once the backend was ready one of my other teammates created a new Github repository and I pushed up the code. Another great side effect of being forced to work remotely was that we all got some much needed practice using GitHub. It forced us to commit more and we really got to see the beauty of being able to work on the same codebase remotely. GitHub is a powerful tool, but it too requires great communication between everyone on the team in order for it to be used correctly. We only encountered one merge conflict, even though we made over 60 commits. That merge conflict was also a great learning opportunity on how to avoid them in the future.
As the project continued to evolve, we decided to divide the workload based on which technologies we each wanted practice on. As someone who had previously struggled with CSS, I took this as an opportunity to really dive in and force myself to improve at something that I normally shied away from. I basically went from novice to competent in a few hours. I also forced myself to use my Googling skills, and to only ask for help if I was really stuck. To my amazement I was able to solve almost all of the problems myself, while at the same time learning just how awesome and powerful CSS really is. I went from initially disliking CSS to being an avid reader of CSS-Tricks by the end of the project. There is a special kind of joy to be gleaned from slightly adjusting margins and playing with fonts, in addition to all of the other amazing things you can do with CSS.
One of my other teammates expressed a desire to get more practice using JavaScript, so she coded the functionality of our frontend. We were always in contact, and another cool side effect was the feeling of excitement I got whenever she pushed up another page for me to style.
By the end of the week we had a beautiful, and working, application that we were all proud to present to our cohort. Mod 2 was tough, but it was during Mod 2 that I learned the value, and fun that can be had when you collaborate with others.
Top comments (0)