During the summer of 2018, I completed an internship program at 8th Light, a software engineering/design consultancy. This was my first exposure to “real world” software engineering. Here is my story.
I remember the first time I heard about testing. In late 2015, I applied for a position at 8th Light. I had heard about their apprenticeship program and thought it would be the best environment for me to learn as I learn the quickest when I get a chance to observe other people. Even though I was only 4 courses into my computer science bachelor degree, I felt confident that I could handle an apprenticeship. Even with my limited knowledge/experience, I knew I would be able to learn the craft quickly and be prepared for a full-time position by the end of it.
8th Light tasked me with writing a tic-tac-toe game in Ruby during the application process. So I had to learn Ruby. I dived into a book and some tutorials to learn how to write classes, methods, get input, print output, and utilize some of the standard classes in Ruby. I submitted a working tic-tac-toe command line game and received feedback. This feedback was a gut punch to my confidence.
The majority of my ‘weak’ feedback was minor. My folders were named/structured unconventionally. I used counters in most of my loops because I came from learning basic C++ in my college courses. All my classes were in one file. I nested conditionals too deep. I used class variables. Easy fixes.
It was the minority of my ‘weak’ feedback that blindsided me. I had no tests and the interface was deeply coupled to rest of the application. Two years later, I still remember my response - anxiety. I had no idea what this feedback even meant, let alone how to integrate a fix. I looked to my usual learning resources but couldn’t find anything that I could easily understand. In the book I had bought to learn Ruby, the testing chapter was at the end. There was a long span of intimidating pages between that chapter and the spot in the book where I stopped understanding things.
I probably could have figured them out if I wasn’t completely starved for time. I was juggling a full-time job, a part-time college workload, and a one year old child. My application had to take a backseat to my current obligations. I would conquer these concepts one day, but that day felt so far away. I began to worry that my career change may take too long. This was very discouraging.
In early 2016, I notified 8th Light that my other obligations had to take priority over the application process and told them I would pursue a position at another time. For good measure, I purchased Practical Object-Oriented Design in Ruby (POODR) by Sandi Metz hoping it would clear some of the fog, but it didn’t. I struggled with the concepts of testing and interface decoupling while continuing to pursue my computer science degree and learning what I could about programming, on the side.
Fast Forward Two Years
Two years later, this happened:
Are you looking for your first job in software? Our summer internship program in Chicago will give you experience delivering high-quality, well-crafted software in a team environment. We’re accepting applications through this Thursday evening—apply today! https://t.co/vQqK6fACRy— 8th Light (@8thLightInc) May 15, 2018
By now, I had a solid understanding of how to write code in a few different programming languages. I had some basic exposure to MVC frameworks. My long-term goal at the time was to build an application for my own use and to use as an example to showcase my abilities. Not only did I want to write good code that would stand the test of time, I also wanted to mimic the industry’s best practices for project management. I didn’t know where to start. I applied to the internship program hoping to obtain the knowledge I was seeking. I was hopeful that this was exactly what I needed at exactly the right time. When I chosen to be one of nine interns, I was extremely grateful.
A Good Sign
The first good sign (read: confidence booster) was when we were tasked to read POODR. As I mentioned earlier, I had attempted to read the book in early 2016 after stepping away from my first 8th Light application. At that time, I was able to understand some of the techniques discussed in the book, but not very many of the concepts. I learned what to do and how to do it, but I didn’t understand why. With the background knowledge I had accrued over the previous 2 years, the book made much more sense.
The Internship, Summarized
For the first half of the internship, I worked on a Mastermind command line game (my work can be found here). I made a Trello board where I placed all the features individually as stories. I estimated the work I would be able to get done during each week, while balancing blogposts, pairing katas, helping the other interns, and book reading. After each weekly iteration, I would submit a pull request to my Github repository with the new stories to be reviewed by a volunteer software crafter at 8th Light. The peer reviews from pull requests were incredibly helpful to me. I was also able to pair program with two crafters. One helped guide me through decoupling my interface from my model and testing it (😁). The other introduced me to the benefits of continuous integration and helped me add TravisCI to my repository. During this time, I finished POODR early and was able to pick up Extreme Programming Explained by Kent Beck and Cynthia Andres.
Reading this book while actually practicing many of the techniques he and Cynthia Andres discussed was the defining moment of my internship experience. It all made so much sense. These were software design best practices. I was finally learning the what and the why. This made me feel really good about my abilities. I was confident and enthusiastic about learning again.
When we moved on from the Mastermind exercise, we were introduced to a legacy (4.0.2) Rails application. There was a layer of abstraction in between the persistence layer (database) and the model. This, we quickly learned, was a design pattern called Repository. This was my first exposure to the concept of design patterns and I dove in head first, buying Design Patterns: Elements of Reusable Object-Oriented Software by the “Gang of Four”. An incredible resource that I can reference for inspiration in designing my own software. The first two chapters were illuminating by themselves. Without even diving into the complicated design patterns dictionary/glossary, I began to understand the importance of these design patterns, and I began to think in more abstract ways. This motivated me to make major changes in how my Mastermind game worked.
I should note that I had the advantage of possessing background knowledge in web frameworks. I took a course in web development with Python and Django and read through most of the Go Web Programming by Sau Sheong Chang. Thus, I had been previously exposed to the fundamental web programming concepts such as routing and REST APIs and how to make simple web applications while following a guide. I also had experience reading code written by others from exploring various open source projects. Almost everyone else was in completely new territory. I tried to use my advantages to help the other interns learn, while pairing and in groups.
The fact that Rails was brand new for many of us made estimating our stories as a group difficult. We didn’t know how long features would take because we weren’t certain of the scope of the work. It was also difficult to coordinate pairing hours because the program had no defined schedule as many interns had job and/or school obligations. I also had experience using documentation and reading guides/tutorials - valuable tools that were disregarded by some of the other interns.
Now that I understood testing and TDD, one technique I experimented with was using the existing tests to understand what a class/object was doing. This was incredibly productive. One of the pages on the application was a reporting page that showed graphs and charts of the application data. One of the models wasn’t fully implemented and the reporting page was pulling data from a fake API instead of the actual database (because a database table for that model didn’t exist). By following the old tests to define the behavior of our new model, we were able to create a new one with the correct methods where we could just replace the fake API class with our new model in the reporting page controller and all of the correct data would display on our charts/graphs. We continued to add features, tests, and fix bugs for a few weeks, as our group dwindled in size due to school starting for some.
On our last day we held an introspection with the internship director to introspect on working as a team on the Rails application, as well as parts of the entire program.
A Renewal of Confidence and Enthusiasm
The internship was great for me. Some of the other interns didn’t find it as beneficial to them. I took what knowledge was given to us, was able to combine it with my previous understanding, and took off with it. Things were finally making sense under the umbrella of good software design. I learned everything I wanted to learn and more. I made improvements to my learning strategy. The program also renewed my confidence and enthusiasm for software. I was lost before. Stuck in my own brain soup, unable to connect everything together on my own. Luckily for me, I had some amazing guidance when I needed it most. Thank you to 8th Light and the crafters who helped with the internship for leveling me up as a developer.