My First PR at Fieldwire

Introduction

I graduated from Carnegie Mellon University with a Master’s degree in Software Engineering and joined Fieldwire as a Software Engineer as my first job after completing my education. That being said, during my undergraduate studies, I did quite a few internships and worked on several real-world projects. I have interned at a research lab, an early-stage start-up, a mid-sized insurance company, and an online auto re-branding and auctioning company. Beyond that, I have also contributed towards the development of several applications run by various departments and research labs at Iowa State University and Carnegie Mellon University. Needless to say, I have had many first PRs at a lot of places and have been on-boarded on a new team or project more often than billionaires launch themselves into space!

First Task

Given my experience with onboarding, I expected my first task at Fieldwire to be pretty standard - I would be assigned a fairly cosmetic task that will help me get familiar with the processes followed by all the developers. The task was to change an error message. So far, everything was going as I had anticipated it to go. The task was assigned to me on the Fieldwire platform and had a lot of context around the expected changes as well as URLs to necessary resources. One of the URLs pointed exactly at the file that needed to be changed. This was new to me. Traditionally, I would have to spend at least a few hours reading or asking around to figure out precisely what needed to be done and then another few hours navigating a completely foreign codebase to make the changes.

Even before I could jump on a Zoom call with my on-boarding buddy Mark to do some pair-programming, I knew exactly what my changes would look like. Having someone with a little more background at the company pair-program with you on your first task takes a lot of pressure off of your shoulders. I explained what I understood about the task to Mark and he was quickly able to fill in the gaps that I had in my understanding of the task at hand. In a quick 20-minute Zoom call, I was able to make my first commit with the changes requested in the task. It seemed that all that was left was to raise a PR, which is what I did. Mark walked me through how each PR needed to be formatted and let me work off of a template that he followed while opening a PR. Just as I was about to open the PR, I realized that we never tested the changes we made.

Testing

I was not completely sure what the best way to test changes to an error message was. I followed Mark’s advice and added a comment to the PR asking for suggestions. I added a couple of reviewers from the Platform and Core teams and soon one of the reviewers commented with an example I could follow. I immediately took a look at the example and realized that I had no idea how RSpec worked. I had been completing various LinkedIn Learning courses as part of my onboarding so I thought I would take a look at some courses that taught RSpec. The courses helped me get accustomed to not only the syntax of tests written in RSpec, but also best practices of writing tests and some tips and tricks around writing tests in different scenarios.

I used the newly acquired knowledge of RSpec, and the example provided to me in the PR comments, to write the test and subsequently received the approval of the necessary number of reviewers. At this stage, I truly believed I was done after I merged my branch into the dev branch. After all, I had understood the task, written appropriate code, pair-programmed with a more experienced engineer, written tests, received the required number of approvals from reviewers, and merged my branch. My manager Rahul congratulated me on my first successful PR and I moved on to work on a new task, as well as learn new material.

E2E Ownership

About a week later, I was contacted by someone on the Platform team to verify that my changes, to the error message, were reflected on the staging deployment. They also shared a document that talked about a developer’s ownership of a task. This was quite new to me as at all my previous places of employment, end-to-end ownership was not practiced to a T. I was impressed by this practice since this not only ensured that the changes were up to the mark, but also gave a sense of ownership and responsibility to the developers. I would rather support my changes through the different development cycles than deploy hotfixes to production.

Conclusion

With the help of some teammates, I was able to verify that the application reflected the changes I made and was able to move my task from the Merged column to the Verified column and soon to the Released column. I got a shout-out from my manager on Slack. There it was, another first PR successfully made its way into the wild, but this time it taught me a lot more about the processes and, more importantly, about the culture at Fieldwire.