The Three Pairs of Pair Programming

Pair Programming. For some it’s a necessary evil. You’re in a program where they believe in the process and force you to engage. They say things like “we believe you’ll find that you learn more from pair programming than you do on your own”. I don’t buy into this concept, unless of course my partner is Google and your conversation is held to blubs like, “better way to understand hooks than official Sequelize docs”. I find I learn most from the one on one battles with the machine (my wonderful 2011 who, despite these battles has been loyal for the past seven years). I find strength in the struggle. When I’m eye to eye with a 1,000-line error and I’m on the last Stack Overflow entry of the first page of my Google search (does anyone actually check the second page?) Some people love pair programming. It can certainly be illuminating and you can learn a lot. It just depends on the pair. In a way its kind of like dating in that you know fairly quickly whether or not the first encounter is going to be very good or very bad. This makes pairing up a very nerve-racking and potentially disheartening process. In the end, you either end of feeling high on life or at home watching The Office wondering why you ever tried pairing in the first place. I guess for these reasons, I just like the stability of knowing what I’m going to get when I code alone. I hope that doesn’t speak volumes about my love life…Anyway, these are the three pairs of pair programming. I hope you find yourself identifying with at least one or two of them.

Pair 1: The Dynamic Duo

This is the good one. It’s the reason why we pair in the first place. You start out with some small talk and find out that you both like basketball and that you’re both not sure that the mid-range jumper is totally dead. (Sorry non-sports fans, that’s the deepest sports reference I’ll make this entire post. I promise). You hit the code and things are rolling. They’re propelling the progress forward and each time there’s a bug, you come out spraying Raid. When you hit real roadblocks, you reason things our together. You listen to each other and collaboratively come up with a solution. And as soon as you pass this hurdle, it’s all high-fives and good vibes again. You’ve done battle together and neither of you would have made it without the other person. You’ve learned a lot from each other and you’re both better programmers for it.

Pair 2: The Fast and the Furious

Here is where things start to get ugly. Person A has a computer science background. They’ve been playing with computers their entire life and they just see code like they’re Neo from the Matrix. They like being the driver because they can’t always necessarily explain their thought process to their partner. The rare times they do get stuck, they don’t turn to their partner because they only trust the voice in their head to figure out the problem. They try to explain what they’re doing, but mostly they think their code is speaking for itself. They take their partner’s silence for understanding. They’ve finished every workshop so far, and they’re not about to slow down and risk breaking that streak.

Person B is looooooost. They were bartending before they started boot camp. They felt pretty good about their progress until they paired up with person A. They’re too embarrassed and intimidated to speak up and say they have no idea what’s going on. They want person A to pull over and let drive, but they’ll just end up making a fool of themselves. They can just do the workshop over again tonight or maybe even this weekend. Actually they wanted to do CS Saturday this week, and they’re supposed to have dinner with their parents on Sunday. They don’t understand what Person A keeps doing with that question mark. And what’s the deal with all of the forEach’s? What happened to the tried and true for loop? They should have never come here. They were making pretty good money as a bartender. Maybe they’ll watch the episode where Dwight puts on a fire drill without telling anyone tonight. Who cares about having a career anyway?

This may be a bit of a dramatized example, but I believe many of us have found ourselves in a similar situation. You may have been Person A or Person B. If you find yourself identifying Person A, slow down or pull over. Maybe you should try navigating more often than driving. You may find that talking a partner through a problem that you could easily solve on your own is a lot more challenging than you would think. Don’t let you code speak for itself. Explain your thought process. Ask your partner to explain you code, and have them ask questions about it. Don’t take head nods and nervous smiles for understanding. If you find yourself coding along for ten minutes straight with no dialogue, it may be time to pump the breaks. If you’re like Person B, don’t freak out. There’s always going to be brilliant people out there that make you want to give up on everything, especially in programming. If you’re paired with one, take it as an opportunity to learn from them. Speak up when you feel lost and get them to explain their code. Ask for them to pull over and don’t feel nervous about being a slow typer or continuously making errors. Everyone is here to learn. Have a good humility about yourself. It will help in the long run.

Pair 3: The Lonely Launderers

This is the grand finale and possibly the worst pair of all. It’s where you’re both lost and you’re not making any progress. Person A is a little less lost than Person B, so they’re trying to steer the ship, but they’re not making much progress. They’re not listening to their partner at all. They’re so focused on their own ideas that they can’t process suggestions. They call help tickets, which take longer than usual. This gets them to the next page of the workshop where they get stuck for the next hour. The review video can’t come soon enough. They’re both embarrassed and frustrated by the situation. They avoid eye contact in the halls until they share a few drinks together at Killarney’s.

I identify most with this pair, specifically Person A. I like coding alone. As I’ve said before, I like the struggle of the one on one battle. When I get stuck on a bug or learning a new library, I become obsessed with it. I block everything and become laser-focused on the problem. I get frustrated and begin trying all crazy things without consulting my partner. When I started at Fullstack, I was terrible at pair programming. I was too proud to admit when I was completely lost. Often when working on personal checkpoints or problems, I would refuse help from classmates because I wanted to learn everything on my own. I would even refuse the help of Stack Overflow. This was obviously ridiculous, especially the last part. (Stack Overflow is the greatest gift we as programmers have ever been giving). Don’t be like me. Listen to your partners and crack a joke about how lost you guys are. Accept help when you need it, and put in a help ticket for every page on the workshop if you absolutely need to. Everyone comes to Fullstack to learn, and there’s a great deal you can learn from your fellow students. The greatest learning and fulfillment may come from the one-on-one battle, but sometimes a tag-team match can be just as fun.