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.

I submitted my first pull request today

This year Xactware turned 30. We've been rocking the insurance software scene for a long time. One of the reasons I initially got my foot in the door at Xactware is because they employ a significant number of manual software testers. No coding experience required. Months ago when I knew that code was my future I began to look around Utah County for manual testing positions so I could get started somewhere. Among all the startups that I perused it seemed that they were only interested in test automation engineers. 

It makes sense why manual testing positions are few and far between. Code written by an automation engineer can do the work of dozens of manual testers in a fraction of the time. Not only is it more efficient but in most cases the test results and feedback are more accurate and beneficial in churning out a better product. 

Just a few years ago Xactware finally started  taking automated testing seriously. Only a month ago we named our first Director of Test Automation. I personally believe that there is no better time to get into automation at this company than right now. Imagine the impact I can leave on the products I'm testing while we are all charting new territory in automation.

From day one I made it clear that I want to work in automation and now the day that I accept that position feels closer than ever. 

I took a huge step towards becoming an automation engineer today. For the last three weeks or so I've been meeting an hour or two every week with one of the test automation managers. He's been really helpful and patient by walking me through the process of writing simple tests and building/updating the testing framework.

I wrote six tests and I added two pages to our testing framework and damn am I proud of that. We managed to get all of these tests to pass and the framework updates and additions I made are solid. After cleaning up the code, pulling down changes from our remote repo, merging my additions with those, and finally pushing everything back up to the remote repo... I was ready to make my first pull request. Pressing that button felt like I had stepped into a new world and it felt good.

I never imagined that just getting my foot in the door of a tech company would afford me so many opportunities or that I would find so many people to help me along the way. If you are interested in learning how to code and eventually making a career out of it consider a manual testing position or something similar. Make your aspiration to move on to bigger and better things from the beginning. Hopefully you will find as many opportunities as I have at Xactware.

What the hell is version control?!

Learning how to code on your own can often be a lonely endeavor. Myself and many others work full time jobs in addition to self-teaching code through tutorials and books on our own time. It often isn't feasible to regularly attend classes or coordinate with others to work through projects.

 I can really only speak for myself but the majority of the small projects I work through to master specific concepts are done by me and only me from start until finish. Because of that I wasn't even aware of the concept of version control until somewhat recently. Once I understood the importance of it I sincerely wish I had covered it earlier on.

The spare time that I devote to coding is with the intention that I will one day (hopefully sooner than later) accept a job as a full-time software engineer. The thing is, the coding I'll be doing as part of a development or test engineer team will vary GREATLY from the practice work that I'm doing now. The key part to that is working as a TEAM. Until now all of the projects that I've completed have only involved one person - ME. When you work as an engineer for a company you typically are not the only person assigned to work on a product. So why does that matter?

If you've learned even a little bit about code you've seen that even small errors can cause HUGE issues in code. Now think about the fact that several different engineers are all simultaneously writing code on the same product. How will your code interact with Joe Schmoe's code? How will you share your code among team members? Are there ways to predict how your code will interact with the rest of the solution before you implement it?

The answer is YES. The answer is VERSION CONTROL.

Modern version control almost always means Git. I was aware of Github and it's uses as a budding developer long before I began to understand how Git itself is actually used. I am not an expert in Git, in fact I've hardly used it professionaly at all, but I would be happy to list some great resources to learn git.

• Lynda.com - Git Essential Training with Kevin Skoglund - This six hour course masterfully explains the history and concepts of Git and provides an excellent example of how it is used
• Codecademy.com - Learn Git - This course is only two hours and focuses more on git workflow
• Github.io - Git Tutorial - Github itself provides a tutorial! Learn at the source!
• Learn Git Branching - My future manager in automation testing recommended this interactive course to become a Git ninja. Seems more interactive than the others.

After delving into some of these resources take a gander at the image below. If it makes some sense to you then you are going in the right direction!

In closing I want to encourage you to begin impletmenting git commands in your projects. I don't care how small the project is or if you are the only person to ever even see it, having these concepts in place will do wonders for you when you finally find yourself working with a team.

Apple is a big reason why I'm here

Where do we find our inspiration? How long will it sit in front of us before we recognize what it is and what the Universe wants us to do?

I want to talk about two specific moments of inspiration that are related.

On June 2nd, 2014 I tuned in to the online stream of Apple's World Wide Developers Conference. For years I try my best to watch Apple announcements and keynotes live and that morning was no exception. This Developers Conference was unique where there was an actual focus on DEVELOPERS.

There was plenty of jargon being thrown around that I wasn't understanding. Instead of tuning out the noise, something stirred inside of me and I was intrigued. The audience gasped when Craig Federighi said "We've used Objective-C for 20 years, and we love it. But we wondered what we could do without the baggage of C."

"We have a new programming language"

I sensed that something important was about to happen. Apple announced Swift and announced soon after that the language was to be open source. The feeling in the room seemed to be electric and it was contagious.

The prospect of Apple creating a tool so powerful and complicated is fascinating to me. Its one thing to create phones, tablets, and computers but it never crossed my mind that you could create a language. Of course looking back its silly that thought had never crossed my mind, where did all of the other programming languages come from? What matters is that it was the first time I wanted to learn one.

Two days ago Tim Cook, CEO of Apple, came to Salt Lake City for a Q&A session hosted by Senator Orrin Hatch. A few years ago I got in an argument with Orrin Hatch about the Patriot Act (he wrote it) but that is neither here nor there. I went to the event and reunited with an old friend who showed me the ways of Apple long ago. I was happy that I had secured a couple tickets because I was on a wait-list for several days.

I was especially interested in Tim's thoughts concerning encryption and the future of augmented reality. He also claimed that Apple isn't interested in being the first to release a product, nor producing the most, but to make the BEST. I like that. Sure Apple's products aren't always the best but you can't argue that there is a significant level of polish to be found in everything they produce.

We may have snuck backstage only to be stopped by one of the Senator's aides. We still had our chance to say hi, shake hands, and my friend had his iphone case signed by Tim Cook in the hall afterwards.

Being in that room with such a large chunk of Utah's tech industry was electrifying. Once again Apple swooped in and inspired me to not just become a developer but to become a GREAT developer. I will carry these moments with me as when I inevitably get frustrated learning this stuff. My friend documented our adventure in his weekly vlog here: