Pros and Cons of Pairing
I originally wrote a short rant about how uncomfortable I found pair programming from the beginning of bootcamp.
I’m updating the post because, well, I can do better. I can write a better post for people who don’t know what pairing is. I can write a better post that explains my opinions at the time and more accurately reflects the full pairing experience.
SO, below are the basics to pairing and the pros and cons, in my experience thus far (which is now the end of Week 6).
I bet you thought programmers were loaners, right?
Pair programming is two people sharing a computer, working on the same code, together. The theory is that better code is produced together than separately because errors can be noticed quicker and corrected and quality is improved when someone else works out a problem with you – two heads are better than one.
Driver: The driver has hands on control of the computer and is the one physically writing the code.
Navigator: The navigator scans for errors and improvements by being in a more observatory role.
Switch: In class, we switch off every other exercise or so. In the real world, I’m not sure how switching works but it’s definitely expected to take turns in each role.
Better than spell check! Your partner usually eagle eyes all the missing brackets, semicolons, etc, immediately. Likewise, your own eagle eyes get sharper, helping you prevent errors when coding alone.
Better than asking someone unfamiliar with the code. Pairing is cool because you can bounce around ideas and experiment with someone who can follow along. They also know what has and hasn’t worked, so you don’t have to explain every decision to someone, in theory they get why you might try out a certain type of code.
Collaborating leads to chiller environment vibes and more excitement for coding. It feels great to solve a code issue on your own. But it actually feels more rewarding to solve a problem with your pair. Twice the excitement, satisfaction and payoff because chances are, you’re coming up with something more powerful and inventive while teaming up versus rolling solo all the time.
Takes cognitive practice. You have to be aware of what your partner needs from you and what types of partner you respond well to. Everyone has different communication styles that greatly affect the outcome of an interaction. Pairing has its own etiquette is as much a balancing act as any other social interaction. If you don’t realize this takes dedicated practice (like I didn’t) then you’re likely to run into frustrations.
I’m an independent learner. I prefer to read and then do whatever I’m learning. When I learned how to balance a department store cash room, it helped to first ready the manual, then get it there and start calculating. Same with driving right? That’s why you read and memorize the rules before taking the exam. But there’s more than the permit test. You also learn on the road that some adjustments have to be made for good judgment.
Notes about some of my pairing experiences:
My first partner was ideal. Jesse and I would talk through things and help each other out in different ways. I totally forgot everything about Ruby so Jess was great about walking me through those exercises. I would reciprocate by explaining some html/css positioning and flow concepts, so it was nicely balanced.
All of my partners have been great people. I have learned skills and tricks from them that I would not have learned alone. I don’t know that I have learned core concepts from pairing. Because that’s not really what pairing is meant for; it’s for geared towards colleagues of similar skill levels working through a project together, not for beginners who are finding their way with new information.
When it comes to learning a gazillion languages in a short amount of time, I feel that pair programming can be a hindrance in the beginning. Now that I’m over half way through, I’m starting to see some great advantages from it. The biggest for me, is that having a partner pushes you to do work you don’t want to!