The Beginner’s Guide to Your First Pair-Programming Project

For budding software engineers, the first pair-programming project is usually clunky and disjointed. All coding experience up until that point has most likely revolved around listening to lectures, doing code-alongs, and practicing in some form of a shell inside the terminal by one’s self. I certainly know that mine was. Then along comes that first pair-programming project. Two people must join forces to solve whatever problem has been placed before them with little-to-no experience at doing so in group setting.

The questions begin flooding in. Who will do what? How will we share our code with one another? What if I make a mistake and it breaks my partner’s code? What if I leave my camera on during the Zoom call and do something embarrassing? What if we have completely different ideas as to how to approach the problem. What if… what if… what if…

Panic!

Wait. Wait, no. Don’t panic. You’re fine. I’m fine. We’re fine. Just breathe, and know that I’ve got your back with an outline you can follow that will help ease you into the pair-programming experience. I’ve already made the mistakes so you won’t have to. When done properly, pair-programming can be incredibly rewarding and educational, and almost always yields a better product than had you worked on the project by yourself.

Where to Get Started

The first thing to remember is that you and your partner will not agree on everything. It’s just that simple. There are going to be moments where each of you will have to compromise. When these snags pop up try to remember that you both are on the same team and you both have the same goal in mind; reach minimum viable product by the deadline. Just because it’s not the way you would have done it doesn’t mean it doesn’t work. It is moments like these where it is more important to listen than to speak. It gives you the opportunity to see things from their point of view and possibly learn new techniques that may be superior to your own.

Once that is out of the way it’s time to get on the same page with one another. Creating a user story together is the best way to accomplish this. For those who are unaware of what this is I highly recommend reading ‘Start Writing User Stories for Your Program,’ by Sean Padden. The quick and dirty explanation would be to create a list of all the actions you want to be able to take as the app’s user from the moment you start the app until you close out of it. This creates a roadmap that you can use to guide your decision making as you are coding along as well as a good jumping off point.

‘We get to start coding now, right? We have our stories.’ Almost. There needs to be a shared understanding of the basics of the code before you can each branch off and work on your own. You need a foundation. You need to work together a bit before you can work alone. This is done by deciding one of you to be what’s called the driver (person who does the actual coding and shares their screen), and the other person to be the navigator (person who guides the driver as to what to do, what to write, and researches possible solves for any issues that arise).

Setting Up Your Git Workflow

There are a couple common ways of working together in the driver/navigator capacity. Live Share is an option that text editors, such as VSCode, offer where you can both code on the same files at the same time. This is a very good tool for helping one another, but it is not good at scale when you are working on larger projects in the real world. Git workflow is the real answer. Git workflow is just the recommended way of using Git to so that it is consistent and reliable. It is how you will be working once you find a job as a software engineer, and it offers you the amazing opportunity to make mistakes without breaking the app. It is my assumption that if you’ve made it all the way to pair-programming you are already somewhat familiar with Git. (If you are unfamiliar with Git I highly recommend reading up on it to a greater extent than what I’ll be covering. GitHub offers a guide here)

The driver should set up the environment locally, and then make a remote repository using on GitHub, while the navigator clones their repository using the SSH key as the would with any other remote repo.

The driver will then have to grant the navigator permission to manage access by inviting them to collaborate. This is easily done through the Settings menu followed by selecting the Manage Access menu.

At this point GitHub will ask the driver to reenter their password. Once done, the driver can manage access by Inviting a Collaborator. Search GitHub for the navigator’s ID, and an email invitation will be sent to them.

Now both the partners will be able to push and pull code to the same repo!

CAN WE CODE ALREADY?!

The stage is set; you have your user stories, you have the environment set up, you have a working repository that you can both access. So, yes! It is time to actually write some code. Where do I begin? What do I write first? Who writes it? This is where the driver/navigator relationship really takes to the road. I recommend starting by defining all your classes, making all the tables and migrations you need, and installing any gems that you deem necessary. This will give you each a solid foundation from which you can both build upon.

Doing this together will also accomplish two other things. The first is obvious, that it will insure you both understand the baseline code. The second is more subtle, but equally important. It establishes a working trust with one another. Trusting your pair-programming-partner is paramount. Okay, maybe not paramount. I just like alliteration. But, it is very important. In order to do exceptional work your mind cannot be occupied worrying about what your partner is doing. You have to know that they will execute the vision you both established back at the user stories.

Once the basic code has been written the driver does a ‘git push’ to the master branch of the remote repository, and the navigator does a ‘git pull’ from the same repo.

One Last Step

There is one last step to take before you begin writing more code. You each need to create your own branches separate from the master branch. This is done by typing ‘git branch <name_of_new_branch> in console. (To see a list of all the Git commands just type ‘git’ in console)

Creating your own branch grants you the ability to mess around and test code without fear of breaking the app. Once you know your code works and has been added/committed, swap over to the master branch. Check to see if your partner has pushed any code to the repo since your last pull by typing ‘git status’ in console. If you are up-to-date you can now merge and push your code (otherwise do a quick ‘git pull’ to update your local master branch) While in the master branch type ‘git merge <your_branch_name>’ and the two will merge. If you get a merge error do not fret! Just take your time to read where the issue arose, and follow the instructions that are given to solve it. Once ready, a simple ‘git push’ will send your code up and it will be ready for your partner to pull the next time they hop on to do some work. Hop back on your branch and get back to work.

You now possess the basic tools necessary to begin a pair-programming project with confidence. Don’t stop here though. This guide is only meant to get the ball rolling in the right direction and hopefully give you some great ideas as to how to move forward on the same page as your partner. Best of luck!