A growing trend at agile companies is pair programming. It’s a sort of virtual road trip where a “driver” (who writes the code) and a “navigator” (who reviews the code) sit down at a workstation together to see if two engineers can solve a problem more quickly by working in tandem — and in real time — than by working separately.
Recently, software engineer Adam Chen-Wei and full stack engineer Albert Orlando, who both joined PebblePost in November 2017, tried pair programming when working on the Flight Builder component in PDM™ Manager. Here are their impressions.
Q: What prompted this experiment?
Adam: I had tried pair programming before in a similar position where I had knowledge to share with someone who wanted to know more about a specific framework. And it was very helpful in tackling all different kinds of pain points where the person might not be aware of certain solutions that are out there. Pairing up with someone who has more experience in a certain area can be very helpful.
Q: But it can also be pretty exhausting, correct?
Adam: Yes. That’s partly because of the high level of concentration required to resolve problems quickly while at the same time you want to show your best work. But it’s also because you’ve got someone watching. You try to resolve the coding as quickly as possible so the other person doesn’t have to wait too long. It’s almost like there’s an added social pressure along with the pressure of just trying to solve the problem.
Albert: When you’re working by yourself, you’re only working on coding or coming up with a solution for the task at hand. When you’re working with someone else, you’re kind of doing two jobs at once because you’re communicating and brainstorming and then you’re implementing the code on the spot. It’s almost as if the code review is superimposed on the programming work itself. This can be a big drain on your energy over the course of a few hours!
Q: Did you have any substantial disagreements that were hard to resolve?
Both: [Cross-talk that dissolves into laughter]
Adam: Yes, that was kind of interesting. Sometimes you do get to the point where one person is ready to move on and the other still wants to do a little more digging and try another prototype with another concept. When that happens all you can do is accommodate the one who believes there is an alternative solution. You just have to give it time and, in our case, we actually did find a better solution. The purpose is to try to come up with better code together, and you need to allow each other to express ideas and take the time to explore them further.
Albert: Because we wanted the same outcome and we knew that pair programming was a vehicle to achieve that outcome we were both very open to one another’s suggestions — particularly on my end because I was coming from a place of less experience with this particular framework.
Q: But what happens if you’re positive you’re going down a dead end?
Adam: That’s the most stressful situation — when you realize you have to intervene to keep things from going too far down the wrong road. Most of the time you try to hold back and show patience and try to understand why another approach might be better. But occasionally you just know that it’s not going to work. And these are all decisions that you have to make rather quickly. So it’s an intense process that, again, can cause a big drain on your energy level. When you leave the room, your brain is fried. You just can’t think anymore.
Albert: It also helps to remember that even the false starts can be helpful. That back and forth, with each new discovery, ultimately leads to cleaner code.
Q: So it’s more a two-way street than a teacher-pupil type of thing?
Adam: Yes, for sure. Pair programming isn’t necessarily always about the specific problem you’re trying to solve. It can also lead to insights that involve tooling or maybe a way to debug something. There’s always something that you can learn whether you’re the “expert” or the “novice.” Also, just having fresh eyes to look at a different concept or try a different approach can be really helpful and is a good time-saver in terms of how to write cleaner code.
Albert: There’s a more extreme form of pair programming called “Ping-Pong” that would be cool to try in the future. In Ping-Pong, the driver writes a test and then passes it to the navigator who has to implement the code that would pass the test. It’s a good way to switch the frame of reference from driver to navigator. We just didn’t get around to that this time, but it’s something we’d be inclined to do in the future.
Q: So overall you were happy with the outcome?
Albert: Yes. My key takeaway is this: Several months later, I feel that pair programming really helped me get up to speed and allowed me to contribute much earlier in our development cycle than I would have otherwise.
Adam: It’s an experiment we should continue with. It can be really beneficial at this point because we have a lot of architecture and design decisions to make and it would be a good time to try pair programming to figure out the path.
Q: Are there any tweaks that might make it even better?
Albert: I like using a Pomodoro timer when I work, and I think that could help with pair programming. With this method, you work diligently for 25-30 minutes and then take a five-minute break. Perhaps something like this could help alleviate the feelings of fatigue.
Adam: I think it would be good to schedule when time is less sensitive, like late afternoon instead of in the morning when you might have a meeting scheduled after.
Q: If pair programming were a buddy movie, which one would it be?
Albert: “Bill & Ted’s Excellent Adventure.”
Adam: I forget what it’s called. The one with Jackie Chan and Chris Tucker.
Q: You mean “Rush Hour?” That actually seems like an appropriate title…