photo credit: Rennett Stow
For a developer who’s new to pair programming, it can be overwhelming and difficult to adapt to pair programming practices. As developers, often the natural tendency is to hole away and solve our problems on our own: we thrive on the thrill of achieving the solution. The satisfaction of arriving at that solution on your own can make you feel good, but it has other costs. If you’re new to pair programming and feeling initially discouraged about the dynamics of pairing: Don’t give up! Pairing is a skill that must be developed and honed just like any other one.
arranging your brain
One of the interesting things about pair programming is how it exercises different parts of the brain. Suddenly you are required to manage the social dynamics and conversation of another person while you are working on the problem. A solo developer can shut down that ‘communication’ side of their brain, put the blinders on and go (Something that can affect the quality of your code). If you’re finding yourself mentally drained at the end of a pairing filled day, don’t be discouraged - these are things that I wrestled with when learning how to pair. When working solo it’s much easier to take those 2 minute breaks to check the latest news headlines or your favorite blogs… Something that doesn’t really happen when you’re pairing. It’s so much easier to stay focused when working with someone else on the problem. As you do it more your mind will become more comfortable working for those longer stretches of time (Just don’t forget to take breaks every once in awhile!).
giving up control
As a programmer, I get great satisfaction out of being the ‘master of my universe’. I design the objects, the methods, the properties and make the whole thing fit together. This is all fine and dandy when you’re developing something in your basement in your free time, but doesn’t work so well in a fast paced business environment. Pairing breaks down the barriers of code ownership and knowledge hoarding. A poorly designed module or class becomes significantly harder to rewrite when the functional knowledge of that module is possessed by only one person. On top of that, the developer is much more likely to feel resentment about having all of their precious work thrown away even if it is in the name of better design principles and progress. If you’re new to pairing you may feel frustrated by this. The satisfaction of your paired work is often harder to see if you’re used to developing solo. Trust me when I say that the longer you spend pairing, the greater satisfaction you will find from the ability to tackle tougher problems with the wielded power of two minds working in unison. That entire database model refactor won’t seem as daunting or annoying if you’ve got somebody to share the ride with.
pairing styles
One thing that’s neat about pairing with another person is it opens up many insights into different workflows and ways to tackle problems. People have different ways to approach a problem, and the knowledge transfer between the two developers is huge when working as a pair. People also have different styles of pairing; Some people are more explicit about their thought process and can articulate very easily what they’re thinking. Others may need to a little encouragement to share their thought processes and bring you up to speed. Keeping on the same page can be difficult at first, especially if you’re learning a new framework or programming language. You don’t want to look like an ignorant or unknowledgable person. Having the courage to speak up and say, “You lost me there, can you go over your thought process one more time?” is hugely important. If you’re getting left behind during a pairing session and not doing anything about it, it can nullify the goals of pair programming entirely. Learning how to manage different pairing styles and how to switch mental gears quickly and easily can pay large dividends when you master it.
final thoughts
As someone who is new to pair programming, there have been growing pains I have gone through in order to gain a higher level of development productivity. I’m still going through them as I learn new things each day. If you’re newly switched to pair programming as a development practice and having trouble getting used to it right out of the door, be patient. The product of your work will be much more satisfying if you can share the success of that work with your fellow developers.