Four hours each day at Galvanize’s Data Science program is dedicated to pair programming. Initially, I expected each cooperative experience to be smooth and efficient. With some people, efficiency doubled; however, with others, efficiency exponentially decayed. Therefore, I began my endeavor to understand this phenomenon.
What is Pair Programming?
The structure of pair programming consists of a “driver” and “navigator”, who alternate roles periodically. The driver types the code, while the navigator focuses more on the overall direction of the code.
This approach to coding is common, as it can improve accuracy and quality of work. Though it may require longer man-hours, the decreased volume of mistakes can save a company time and money in the long run.
That being said, my experiences thus far have shown me that this isn’t always true in practice. In fact, it is quite common for there to be frustration among pair programming partners, for reasons such as differences in personality or even coding methodologies. In this article, John Kim, a software engineer at CDK Global, briefly discusses some pitfalls he’s experienced with pair programming.
Why am I Writing This?
From the beginning, I genuinely appreciated pair programming for all it had to offer. My first partner and I worked well together, effectively solving problems and progressing farther than many other teams; I was amazed at our efficiency. However, different partners brought different levels of productivity. I became aware that pair programming can decrease efficiency as well. Though most of my experience has been positive, there have been times I left the exercises dissatisfied with the progress made. In these scenarios, disagreements stop the gears of progress rather than facilitate it. I often leave these experiences exasperated and fatigued.
This starkly contrasts with positive experiences where interaction seems to flow naturally. Both conversation and debate are smooth and constructive, leading to a better solution than either partner could discover on their own. Assignments are completed effectively and submitted early. These experiences always leave me feeling fulfilled and energetic.
I set out with the goal of finding a solution to this disparity; I wanted every partnership to be as fulfilling as the last. Therefore, I hoped to find advice about what I could do differently to make every assignment enjoyable for me and my partner.
Is it Simply Compatibility?
During my endeavor, I stumbled upon an article by the New York Times. The article explained insights Google gained through Project Aristotle – an initiative enacted by the company in order to understand why teams fail or succeed. The article is a fascinating read, and I recommend it to anyone who has some free time.
The insights gained from Project Aristotle challenge many current team building practices. For years, employers and recruiters have been forming teams based on member personalities and skill sets.
For example, the Chief Data Scientist of Sailthru, Jeremy Stanley, suggests companies implement a “Data Day” for potential data science hires to partake in. During this stage of the application process, an applicant works with the team on an open-ended challenge. This gives them a chance to assess their skill and compatibility with the team.
Despite current team building conventions, the research conducted on Google employees for Project Aristotle suggests that the group norms of a team are the only consistent indicator for success.
Among the varying group norms Project Aristotle discovered for each successful team, there were two traits common among them all:
- All members of the team spoke in roughly the same proportion
- There was a collectively high “social sensitivity” – the ability to discern how other members feel based on a variety of non-verbal cues.
Subjectively speaking, this makes logical sense. During my positive pair programming experiences, each person felt comfortable voicing their thoughts, resulting in better communication. I was also better able to discern my partner’s thoughts and feelings through their body language in these situations. The reason for this may be that I often considered my partners in these scenarios as friends rather than colleagues.
However, not every successful team in the study was composed of coworkers who were friends. In fact, one team’s members were complete strangers outside of work. If this is the case, how come both of these teams still exhibited the same common traits?
I believe the teams that attained success did so because they practiced good communication habits. The successful teams created environments where everyone was given equal opportunity to speak, and each member knew what they had to contribute to the team.
A more detailed explanation of Project Aristotle’s findings can be found here.
What I’ve Learned
Though I do attempt to speak objectively, the above analysis was spurred from my own experiences. There are bound to be differences between the program and a company when it comes to pair programming, the most obvious being that we are asked to pair with a new person every day. This may be a major factor, as there is no consistency.
Nevertheless, I’m positive there will be moments when I will be required to work with someone I don’t know well. It is also clear that these frustrations do exist in real life situations. Because of this, I’m glad to have researched and reflected on this topic. I’ve recognized the effort and awareness that is required for smooth cooperation, and I plan to make a more conscious effort in putting these lessons into practice.
By discussing with my partner beforehand and specifying guidelines for working together, I hope to avoid frustration and instead encourage constructive dialogue and consistent communication.
I’ve learned a lot from these past two weeks at Galvanize. However, the most important lessons are the ones being taught to me by my peers. By working with others, I am able to develop abilities just as necessary and beneficial as anything I’ll learn in the classroom.
Galvanized Into Data 