It takes two baby
A primer on pair programming
Software engineering boot camps are hard and don’t let anyone else tell you otherwise. You will have tons of reading and labs, and likely spend more time going cross-eyed looking at a screen than you ever have before. With self-isolation being the norm of 2020 and my classes being online pair programming has become a shiny beacon in the dark, something to look forward to on the calendar.
Considering experience in pair programming
There are common pair programming styles, and each has their own pros and cons. For pair programming to work well it’s most important to first make a game plan, and then stick to it. When deciding on a pair programming method for you and your partner it’s wise to consider your relative experience, and what sort of benefit you’re both hoping to get from the practice. Typically your experience levels will fall into either expert & expert, expert & novice, or novice & novice, and all pairings can be harmonious while pair programming with a little planning and openness to learning and trying something new.
Three Common Pair Programming Styles
Driver and Navigator
Tour Guide
Ping Pong
Driver and Navigator
This seems to be the most common method of pair programming, it’s also the first one I learned. One person takes on the role of driver, and the other navigator. It’s the drivers responsibility to focus in on the code, solving for the small stuff, while the navigator looks at the bigger picture and helps guide the driver through each turn. This method can work well with all experience levels. With driving and navigating it’s important that the driver trust the navigator to lead them through the code. It’s also crucial that you both acknowledge your experience levels and work at a pace that is good for both of you. If you go into driver/navigator feeling like this pup it’s unlikely you’ll get to experience the awesome benefits possible.
Tour Guide
Let’s keep with the travel theme and talk about the tour guide method of pair programming. This method usually works best with an expert and novice pairing. In tour guide programming the tour guide (expert) gets in the driver seat and navigates themselves through the code while talking the tourist (novice) through every move their making. This method can also use with the roles reversed, where the novice takes the wheel, and may likely fail. It’s effective because while the novice works and talks through the problem the expert observes and then helps guide and give feedback.
Ping Pong
Ping pong pair programming (try saying that 5 times fast) is rooted in Test Driven Developement (TDD). Instead of one person guiding the other, or teaching the other, ping pong works in a very different way. First one person writes a failing test and sends that on over to their partner (ping). The partner then takes that failing test and writes code to make it pass (pong). Once the code is passing the second person writes a new failing test and sends that back to their partner (ping). You can also take the extra step of refactoring the code together between the pong and ping.
Before you start pairing
Make a plan. Instead of just jumping straight into writing code take some time to develop a plan together. What are the goals of this programming session? The deliverables? Pre-requisites? Write them down. Taking this time before you even touch the code puts four eyes and two minds on your goals, making it more likely that mistakes, errors, and oversights will be caught before anything is broken. Find your problem, devise a solution, then chart out a plan to get there.
Be like Elizabeth Warren. Have a plan for that!
Time management and rotating pairs
The Pomodoro method
Once you’ve decided how you want to pair programming, what your issues are that you need to fix, and started making a game plan it’s time to consider, well… time management. There are a multitude of ways to divide up and manage your time, but one of the most famous methods is perhaps the Pomodoro Technique. The way this technique works at it’s most basic is that you set an alarm for 25 minutes and get to work. When the timer goes off you stop what you’re doing, and take a short five to ten minute break (a real break, don’t do other work like checking or writing emails; go for a walk around the block, stretch, drink water, etc). For every four pomodoros you’ll then take a longer 15–30 minute break.
If the Pomodoro Technique doesn’t seem up your alley determine how long you’ll work before taking a break, or switching roles and set reminders or timers on your computer or phone. If you don’t you’ll often realize 3 hours later that you haven’t stopped.
Rotating pairs
If your team allows for it, consider setting up rotating pairs. After a pre-determined amount of time pair programming (usually measured in days, not hours) one member of the pair will leave and a new partner will come onboard. At the top of this shift it’s up to the remaining partner (the anchor) to catch the new partner up to speed. This helps solidify understanding of the code, allows for fresh eyes on any issues you may have been happening, and it pushes to normalize the need to stop and re-evaluate where you are and how that impacts your goals and any need for adjustment. It’s not necessary, but it is important to keep the same anchor on a project whenever possible. Having a constant source of knowledge helps prevent repeating work later, and keeps information from getting lost.
There are other methods of pair programming out there, I recommend seeing what works for you. And know that no matter what your experience level there is something to be gained from engaging in pair programming as long as you’re open to it.
