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…


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

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

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!


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

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!

A climate scientist turned software engineer