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 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 framework, 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.

Study your coworkers' commits

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 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.

 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, in addition they will be better able to find bugs and make valuable recommendations for you with less material to review. 

Seek input from more than one engineer

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 would have possibly merged several code changes that would have caused issues down the road in our product. Not only that but I 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.

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 then 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.

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

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 is 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.

Whenever you make code changes, even changes that are suggested by more experienced engineers, test your code afterwards to make sure everything is running 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

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

Take my advice with a grain of salt, after all I really 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.