addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Austin Pair Programming Circle & Code Camp Pages

Resources | Project Repo | Prep Instructions for AngularJS Loopback

Things to keep in mind when pairing...

1) Share Everything

In pair programming, two programmers are assigned to jointly produce one artifact (design, algorithm, code, etc.). The two programmers are like a coherent, intelligent organism working with one mind, responsible for every aspect of this artifact. One person is typing or writing, the other is continually reviewing the work. But, both are equal participants in the process. It is not acceptable to say or think things such as, “You made an error in your design.” or “That defect was from your part.” Instead, “We screwed up the design.” or, better yet, “We just got through test with no defects!” Both partners own everything.

2) Play Fair

With pair programming, one person “drives” (has control of the keyboard or is recording design ideas) while the other is continuously reviewing the work. Even when one programmer is significantly more experienced than the other, it is important to take turns “driving,” lest the observer become disjoint, feel out of the loop or unimportant.

The person not driving is not a passive observer, instead is always active and engaged. Just watching someone program is about as interesting as watching grass die in a desert. In the pair programming survey, approximately 90% stated that the main role of the person not typing was to perform continuous analysis, design and code reviews. “When one partner is busy typing, the other is thinking at a more strategic level – where is this line of development going? Will it run into a dead end? Is there a better overall strategy?”

3) Don’t hit your partner.

But, make sure your partner stays focused and on-task. Doubtlessly, a benefit of working in pairs is that each is far less likely to “waste time” reading e-mail, surfing the web, or zoning out the window – because their partner is awaiting continuous contribution and input. Additionally, each is expecting the other to follow the prescribed development practices. “With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won’t . . . the chances of ignoring your
commitment to the rest of the team is much smaller in pairs then it is when you are working alone.

4) Put things back where they belong.

The mind is a tricky thing. If you think about something enough, the brain will consider it a truth. If you tell yourself something negative, such as “I’m a terrible programmer,” soon your brain will believe you. However, anyone can control this negative self-talk by putting these thoughts where they belong, in the trashcan, every time they start to creep into their brain. The surveyed pair programmers indicated that it was very difficult to work with someone who had a great insecurity or anxiety about their programming skills. They tend to have an “If I work with you, you might find out I’ve never coded with exceptions” defensiveness about them. Programmers with such insecurity should view pair programming as a means to improve their skill by constantly watching and obtaining feedback from another.

Also, negative thoughts such as “I’m an awesome programmer, and I’m paired up with a total loser” should also find their place in the trashcan, lest the collaborative relationship be destroyed. None of us, no matter how skilled, is infallible and above the input of another.

5) Don’t take things too seriously.

“Ego-less programming,” an idea surfaced by Gerald Weinberg in The Psychology of Computer Programming a quarter of a century ago, is essential for effective pair programming. According to the pair programming survey, excess ego can manifest itself in two ways, both damaging the collaborative relationship. First, having a “my way or the highway” attitude can prevent the programmer from considering others ideas. Secondly, excess ego can cause a programmer to be defensive when receiving criticism or to view this criticism as mistrust.

Conversely, a person who always agrees with their partner lest create tension also minimizes the benefits of collaborative work. For favorable idea exchange, there should be some healthy disagreement/debate.

6) Wash your hands of skepticism before you start.

Many programmers venture into their first pair programming assignment skeptical of the value of collaboration in programming, not expecting to benefit from or to enjoy the experience. Two skeptical programmers joined together in a team, could certainly carry out this self-fulfilling prophecy. In the pair programming survey, 91% agreed that “partner buy-in” was critical to pair programming success.

Taken from “All I Really Need to Know about Pair Programming I Learned in Kindergarten

Table of Contents

Page title Most recent update Last edited by
Prep Instructions for AngularJS Loopback November 6, 2014 3:57 PM Julia J.
Project repo! May 31, 2014 4:40 PM Julia J.
Resources August 24, 2015 8:08 PM Julia J.
About Austin Pair Programming Circle & Code Camp November 6, 2014 3:58 PM Julia J.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy