My Internship Experience: Learning Through Research and Reproducing Issues

As a graduate of Epicodus, a code school here in Portland, OR, the projects I had worked on were mainly created from scratch. We built Pig Dice games, tools to convert English into Pig Latin, and home pages for animal adoption shelters (which may have been housing pigs).

The curriculum was written with new programmers in mind, and in order to ensure we were all on the same page, it provided tutorials on not only the programming material to be learned each week but also on how to configure our machines for the projects we were to build.

Upon starting my internship at Planet Argon, however, the tasks we took on were more along the lines of, “Here’s access to the repository, and here’s a ticket on an issue we’d like you to fix. Have fun figuring it out!” Don’t get me wrong, the folks here were plenty helpful, but they were, of course, busy as well, and as any developer or IT personnel will tell you, getting your machine and environment set up yourself is one of the challenges that come with working in the field.

So, the task at hand was to set up the project (get it running on a local server), and then fix it.

Getting the project set up didn’t turn out to be too difficult. The README.md file had enough information and steps for me to set up the project. By working alongside my fellow intern Reese, we were able to figure out the rest.

Once I got the project running on localhost, I was ready to code! However, there were still a few steps to figuring out what was wrong, and I soon realized that debugging code in an existing project was going to be A LOT different than the type of programming I was used to.

I realized that between setting up the application on localhost and actually beginning to debug, I would have to reproduce the problem. I had some data on the state of the application when the bug was hit - generated from Bugsnag, but if I couldn’t reproduce the issue and see it for myself, how would I know when I fixed it?

Reproducing the issue can sometimes be harder than it seems. For some of my projects, I worked on tickets that were issues in the admin side of the site, so one of the steps I needed to do included creating admin login information. For another ticket, there was an issue that was specific to real data in production, so I needed to get a copy of the production data to seed my database with, instead of data from the Faker gem. For yet another ticket, there was an issue in deployment which involved launching the app in production.

While attempting to reproduce the issue, I also often needed to delve into conducting research since many of the tickets I worked on involved topics that were new to me. Take, for instance, the issue of subdomains. On an issue involving a subdomain, or the ‘admin’ in admin.clientsite.com, I realized I could not just run the local version on localhost:3000/ or admin.localhost:3000/. Instead, I needed to use a tool called lvh.me. It’s a free service that resolves itself, along with any and all subdomains, to localhost.

Once I had figured that out, I was ready to switch into full-time research mode for my current ticket. One that I worked on was making sure all images had alt text. My first step: Google. I wanted answers to questions like:

How to generate automatic alt text in html.erb files? Answer: By using the image_tag helper method, alt text gets automatically generated from the file name, if it’s not explicitly given.

What’s the best way to insert images into the application utilizing the asset pipeline? Answer: In order to take advantage of the asset pipeline, use of the image_tag method is much preferred over the direct insertion of an html <img> element.

When I had found myself sufficiently familiar with the differences between the html <img> element and the Ruby method image_tag, including how alt text gets generated for each, it was time to research the use of each in the specific case of this application. The main question I was hoping to answer here was:

Was there a specific reason an <img> tag, which would not generate alt text automatically, was being used instead of the image_tag method?

I used git blame to peruse the commit history of the files in question. Once I was satisfied that the use of <img> tags was likely an arbitrary one, I needed to make a decision of my own - should I leave the <img> tags and just explicitly add alt text to them? Or should I convert all the <img> tags to use the image_tag method instead? I decided to convert all instances of <img> to image_tags. Not only would the image_tag method automatically generate alt text if I didn’t specify what the alt text should be, but this method is considered a healthier way to generate the images on the page using the asset pipeline.

Before altering any code, I asked my supervisor for a few minutes of their time to make sure my conclusions made sense. As a Junior Dev and an Intern, this usually seems like good practice. They were able to give me a few minutes, and we also discussed strategies for testing the new code. Once that was done, I was ready to make the fix. As it turned it, actually writing the code to replace <img> tags with the image_tag method turned out to be the quickest part of the process!

Throughout the process of all my tickets - getting set up, researching the issue, reproducing the issue, researching potential solutions, and actually fixing the issue, I made sure to constantly refer back to the ticket that I was working on.

At times I found myself straying from the task at hand and wondering if there were deeper issues at work or even side effects of my chosen solution. I found returning to the ticket and noting exactly what the issue was in the client’s eyes, helped with that. Of course, I wanted to account for any side effects of my solution, but as a Junior, I trusted the team to keep track of any larger issues underpinning the one I was working on.

In summary, I learned that working ‘in the real world’ is not all about writing new features, nor is it about just jumping in and fixing bugs one after another. During my internship experience, I spent probably 55% of my time researching problems and possible solutions, 35% of my time working on reproducing issues on my machine, and about 10% writing code and testing my fixes. This wasn’t exactly what I was expecting when I arrived at Planet Argon, but it was still an amazing and fun learning experience, and I was still able to fix real issues in the production-stage code, which was one of my main goals entering the internship.