By Ryan Johns November 11, 2016

5 Things I Learned From My First Pull Request

Less than a year ago I decided, like many of you, that I wanted to learn how to code. Although I had next to no experience, I was determined to learn enough to eventually land a full-time job as a software engineer.

Looking to get my foot in the door in the tech industry, I left my job in nursing for a position in manual software testing. Right off the bat, I was presented with the opportunity to learn how to test automation on my own time and eventually earn a promotion to work in a full-time coding position as an automation engineer!

In addition to learning my way around Visual Studio, Git, and C#, I also worked my way through the Pluralsight course “Creating an Automated Testing Framework with Selenium” by John Sonmez.

After finishing the materials recommended by my manager, I was free to begin writing tests, updating the testing frameworks, and submitting pull requests. I had to prove myself in order to get the promotion.

Was I intimidated beyond reason? Maybe.

Without boring you on the details, I somehow managed to scrape together six automated tests accompanied by several small framework updates. The time had come to submit my first pull request to the automation team.

For most teams, a pull request is the opportunity for team members to review the code changes in your commit before they are merged into the “master” branch. Others may also call this a code review

Here are five of the most important things I learned from my first pull request as an aspiring software engineer.

1. Study Your Coworkers' Commits

coworkers

When you first start out, you'll most likely pull down the “master” branch of code that all of your team is working from. This will include the commits, classes, and methods that have already been written.

This is an extremely valuable resource. Most teams will want to keep most of their code fairly uniform by following the same patterns and best practices.

Before writing a single line of code, I meticulously combed through at least a dozen test suites written by the other engineers. It was fairly easy to pick up on how our software tools were commonly used, how the testing framework could be implemented in relation to the automated tests, and what an average pull request would look like.

Because I studied several examples of code written by more experienced engineers on the automation team, I felt much more confident making my own contributions and ultimately submitting my own pull request.

2. Keep It Simple, Stupid

KISS. And no I don't mean kiss your manager's ass. I learned that when you submit a pull request/code review, you are asking other engineers to take the time to thoughtfully read through your code before it is merged with the rest of the product.

When reviewing best practices for the pull request, one of the engineers said to me, “If I see a scroll bar on your code changes, I will send it right back to you.” He went on to say that this isn't ALWAYS the case, but generally engineers don't want to spend all day reading through a large chunk of your code.

The key to keeping a pull request simple is to keep all code changes somewhat related to each other without too many modifications all at once. Not only will this show that you value your coworkers' time, but also they will be able to find bugs more easily and make valuable recommendations for you with less material to review.

3. Seek Input from More Than One EngineerEngineer

When I first submitted my pull request, I received feedback from one individual fairly quickly. He made a minor code change recommendation, but other than that he said everything looked pretty solid. I was psyched out of my mind. My code was clean! Nothing could stop me!

I wasn't brought back to earth until a second engineer came along, reviewed my code, and sent me back a LIST of comments pointing out issues and bugs that I hadn't caught on my own.

Without that second pair of eyes, I may have merged several code changes that would have caused issues down the road in our product. I also learned several ways to integrate my code with testing tools that I didn't even know we used.

This is just a wild guess, but if you don't get a list of comments tacked on to your first pull request, then you are probably not getting the feedback that you need. Either that or you're just the next Kevin Mitnick.

4. Eat a Big Slice of Humble Pie

Did I feel slightly defensive when I first laid eyes on the many comments critiquing my code? I'd be lying to you if I said no. The feeling was fleeting, however.

I learned more in the five minutes it took to read and understand the engineer's suggestions than I learned in the the last day or two of coding on my own. She mentioned tools that I had never heard of that turned out to be extremely important for the tests I wanted to run.

It's a very human urge to shrink away from criticism. It's hard to put your work out there, especially as a beginner, and open yourself up to the judgments and opinions of your peers. I found some useful advice in John's video, “Don't Be Afraid To Look Like an Idiot.”

Although I knew I would be making a lot of mistakes in my code, I also realized it would be the most effective way to learn and move forward. Returning to my code and fixing mistakes turned out to be a much more effective way to retain information as opposed to rote memorization, even if I looked like a bit of an idiot in the process.

You will be served many slices of humble pie. This is a GOOD THING.

5. DEBUG DEBUG DEBUG

This last part may seem obvious to you but I cannot stress it enough. Test your code before submitting your pull request. You'll most likely pull down the “master” branch of code to merge with your changes before wrapping everything up in a pull request. Test your code at least one more time after that before submitting.

After seeing the suggestions from other engineers to improve my code, I was eager to make those changes and commit them as quickly as possible. What I didn't realize was that, by making the suggested changes, I was causing conflicts with the existing tests I had already written. My tests began to fail after I had already committed the changes.

Nobody knows your code better than you do. Keep in mind that when others suggest changes or improvements, they might not understand how those will affect other parts of the code. I approached my colleague and pointed out that their suggestion was causing other parts of the framework to crash, and they agreed it needed to be reverted. Phew.

Whenever you make code changes, even changes that are suggested by more experienced engineers, test your code afterwards to make sure it is running and compiling smoothly. If it's not, then adapt as you see fit and don't be afraid to get help.

You've Taken Your First Step into a Larger World

Code Review

Getting through my first pull request was just the beginning. There will be many more to come.

Your first pull request/code review will be intimidating—count on it. Just remember to follow the patterns in the existing code, don’t bite off more than you can chew, always get a second opinion, and test your code after every change you make.

Also, take my advice with a grain of salt. After all, I only have ONE pull request under my belt, but I sure learned a lot from that experience. Seeing the automation manager eventually approve my pull request was a very satisfying feeling.

Do you have any advice or best practices you'd like to share for new programmers when submitting pull requests or putting up work for code review? Let me know in the comments.

About the author

    Ryan Johns

    Ryan is a test automation engineer at Xactware Solutions. His personal website is RyanJohns.net. He is a new engineer working in Sillicon Slopes, Utah. Follow him on Twitter at @Jedimasterjohns.