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.
Related Services: Agile Development, Full Life Cycle Software Development
[...] Pathfinder Development | Software Developers | Blogs | Growing Into Pair Programming (tags: pairprogramming SoftwareDevelopment methodology) [...]
In my opinion, most of the “productivity gains” of pair programming can be attributed to the fact that it is more difficult to read blogs/articles, chat with friends and play online games when you are programming in pair.
I wouldn’t say ‘most’ of the productivity gains are due to not getting distracted, but a good amount of gain can be had there for sure. I know on one project I was constantly falling behind in delivering the tasks I was assigned, even though I was busy and wasn’t ‘screwing around’ at all.
Once we started pairing, my productivity shot through the roof. I realized I had been spending a lot of time reading work emails about ‘future work’, reviewing requirements, going to meetings, testing and reviewing bugs, responding to IM questions, and other things that were generally ‘helpful’, but were not the tasks I was being measured on, or the tasks that the team was depending on me for.
Once we started pairing more, I worked on the things I explicitly signed-up for, and nothing else, and it was very gratifying. At first I was afraid that some of the other things that I used to spend my time on would suffer, but they have a way of getting managed, and at some point someone would explicitly ask me to spend time on those things, so it became a task to accomplish.
But even beyond the gains to be made by ‘working on the right thing’ I think there are significant gains from pairing that come from doing that right thing even better when you are working with a pair. (but you have to experience it for yourself, I used to say that pairing is awesome all of the time, but I have finally realized that there are some people that simply don’t pair well, and don’t seem to work well in those kinds of teams, and I don’t spend a lot of time trying to convince people anymore. I give them a good intro, and if its not working after 2 iterations, we take them off of the team.)
I’ve heard about “goodness” of pair programming for so long but I’ve never seen any mention about measurement method the authors used to justify its goodness.. How do you really know the improvement really worth a pair regardless of the good feeling they get?