March 16th, 2012 | David Cooksey
A Developer’s Take on Pair Programming
Over the past few years at Thycotic I have spent a lot of time pair programming. Five days a week, eight plus hours a day adds up to thousands of hours. Through my experiences in pair programming I came to a few conclusions about the practice. These represent my take on pair programming, I make no claims as to their originality.
First: Pair programming makes programming social.
This sounds obvious, but it has by far the biggest impact on how you, as a developer, write code. You are effectively writing code as a committee of two, where each member has veto power. All the factors that developers typically do not have to deal with when working alone come into play. Do you like your pair? Does he/she like you? How about respect? Do you work in similar ways? Do you work similar hours? Will you argue incessantly over architecture? Did you or your pair have a rough night?
Second: Verbal communication is as important as technical ability.
Ideas have to be expressed clearly enough that your pair can understand them. The greatest idea in the world may never be attempted if it is not stated clearly. Equally important is the ability to offer clear reasoning when you disagree with an approach. “I don’t like that” is not sufficient.
Third: Two heads are still better than one. Usually.
The caveat to this one is the social aspect. While in most cases two people who are focused on the task can do a better job, the social aspects mean that particular people may be worse together than they are apart.
So, as a developer, what is the best way to pair program? With courtesy. Learn when to shut up and let your pair drive. Learn how often you can interject comments without causing undue irritation. Learn when to push and when to let it go. If you push for your point of view all the time, no one will want to work with you. If you always give in, no one will respect your opinion. Compromise.
What were your experiences with pair programming? If you have never tried it, what are your thoughts on the subject?
June 25th 2009 | PouyaYousefi
Pair Programming in the Time of Swine Flu
I am not a doctor. Nor do I claim to have any medical knowledge other than what I pick up from watching House. I am an “Agile Expert”, a “Test Driven Developer” and a “Pair Programmer”. That last existential statement has faced new challenges with the recent media scare and the possible pending spread of global pandemics such as the H1N1 virus, more commonly known as the “swine flu”.
Inherent to pair programming is the need for close proximity to another person. Although in the past our team has conducted remote pairing with some success, our day to day development requires that two programmers need to sit across from each other at the same pairing station sometimes for several days. Now it does not take a genius to see that this situation would be ideal for the passing and spread of communicable diseases.
Our team has taken many measures to combat the possibility of our team members getting sick. We have alcohol-based hand sanitizers at every pair station, provide alcohol wipes for cleaning the keyboards and pairing areas, and allow for working from home. We hope these measures reduce the likelihood of catching or spreading any illnesses but I believe that an inherent mental shift in thinking needs to occur in order for any measure to really work. That shift in thinking is this: “Do not come to work until you are 100% over your illness.”
I am guilty of coming to work when I feel less than stellar in order to preserve time for an upcoming vacation. Sometimes the urge to get back to work to help the team can sometimes hurt the team instead. Pushing to get back to work when your body is not at 100% can prolong your illness, make you susceptible to other illnesses, and expose others.
Kent Beck, one of the leading minds on Agile methodologies, and the author of eXtreme Programming Explained explains that one of the values of XP is respect. He states that respect is the fundamental value that binds the team and drives the project towards a unified goal. Taking care of yourself should be as important as looking out for your team. The next time you “suck it up” and drag yourself to work because you think it makes you a team player, stop and think about whether or not your staying home might be better for the team in the long run.