Table of Links Abstract and I. Introduction Abstract and I. Introduction II. Related Work A. On the Existence of Pair Programming Skill A. On the Existence of Pair Programming Skill B. On the Elements of Pair Programming Skill B. On the Elements of Pair Programming Skill III. Research Method A. Research Goal and Data Collection A. Research Goal and Data Collection B. Qualitative Research Approach B. Qualitative Research Approach C. Our Notions of ‘Good’ and ‘Bad’ C. Our Notions of ‘Good’ and ‘Bad’ IV. Results A. Two Elements of Pair Programming Skill A. Two Elements of Pair Programming Skill B. Anti-Pattern: Getting Lost in the Weeds B. Anti-Pattern: Getting Lost in the Weeds C. Anti-Pattern: Losing the Partner C. Anti-Pattern: Losing the Partner D. Anti-Pattern: Drowning the Partner D. Anti-Pattern: Drowning the Partner E. Doing the Right Thing and F. Further Elements of Pair Programming Skill E. Doing the Right Thing and F. Further Elements of Pair Programming Skill V. Discussion V. Discussion VI. Summary and Future Work VI. Summary and Future Work VII. Data Availability and References VII. Data Availability and References E. Doing the Right Thing Good pairs maintain Togetherness and Expediency; they avoid the three negative patterns described above. Togetherness Expediency For the case of Getting Lost in the Weeds, both pair members are responsible for restraining their impulses of following new ideas right away. If good pairs get side-tracked, they notice it and work their way back together, as in the next example. Getting Lost in the Weeds Example 4: Session JA1 (04:00–06:40). Early in the session, a simple question by J1 interrupts an explanation by J2, which leads to a misunderstanding that takes almost two minutes to clear up. To avoid Getting Lost in the Weeds, both partners explicitly switch back to the original topic (last two lines in the excerpt): Example 4: Session JA1 (04:00–06:40). Getting Lost in the Weeds J2: “There is the central [News] plugin and multiple processors which each handle one wave. [...] It checks how the file size is changing.” J1: “In what time window are you looking?” [... two minutes of misunderstanding ...] J1: “30 seconds, that’s what I wanted.” J2: “That’s 30 seconds long, the time window. Now I got you. I can show it to you [in the code] in a minute.” J1: “Yes. And the NewsPlugin is doing what in all of this? Does it do exactly this monitoring and the delegation to the individual wave plugins, or what?” J2: “No. The NewsPlugin basically only does—it gets called periodically by the cron server [...]” In contrast to Getting Lost in the Weeds, which the partners do together, Losing or Drowning the Partner is asymmetrical: One pair member is doing something ‘wrong’ to her partner (i.e., explaining too little or too much) who should then try to avert the problem. The next two examples show how good pairs agree on which topics to address and how to limit the scope of an explanation. Losing Drowning the Partner Example 5: Session DA2 (1:30:50–1:38:00). After their somewhat chaotic start (see Example 1 in Section IV-B), the session of D3 and D4 proceeds more orderly. Newly hired D4 explicitly asks his partner multiple times whether he should provide an explanation on some matter, which D3 agrees to: Example 5: Session DA2 (1:30:50–1:38:00). D4: “Do you know about OSGi class loading?” D3: “Class-what? Not really, no.” D4: “Should I tell you?” D3: “Sure.” Example 6: Session JA1 (13:15–13:45). J2 explains code he wrote earlier to J1, who limits the explanation’s scope: Example 6: Session JA1 (13:15–13:45). J2: “It comes from the function ‘getLastFile()’. [...] Shall we look into the function or not?” J1: “No, not now, please.” J2: “Not now, ok.” In both cases, the developers make sure to neither Lose nor Drown their partner. Lose Drown F. Further Elements of Pair Programming Skill We found more elements of pair programming skill which we do not report here, e.g., Agreeing on a Common Plan, which includes picking up on cues that the partner did not understand one’s ideas. Failure to do so threatens the pair’s Togetherness and their work’s Expediency. Agreeing on a Common Plan Togetherness Expediency. Authors:
(1) Franz Zieris, Institut fur Informatik, Freie Universitat, Berlin Berlin, Germany (zieris@inf.fu-berlin.de);
(2) Lutz Prechelt, Institut fur Informatik. Freie Universitat Berlin, Berlin, Germany (prechelt@inf.fu-berlin.de). Authors: Authors: (1) Franz Zieris, Institut fur Informatik, Freie Universitat, Berlin Berlin, Germany (zieris@inf.fu-berlin.de); (2) Lutz Prechelt, Institut fur Informatik. Freie Universitat Berlin, Berlin, Germany (prechelt@inf.fu-berlin.de). This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Pair Programming Proficiency: Is it About Experience or Something Else?

Pair Programming: When Explanations Go Too Far

Pair Programming AI Agent 

Too Long; Didn't Read

Make resilience your competitive advantage

Beyond Anti-Patterns: How Skilled Pairs Stay on Track

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

11 Proven Solutions to Common GitHub Copilot Problems

10x Rockstar Ninja Wizard Vampires

10 Prioritization Techniques for Agile Product Development

10 Online Free Courses That Can Help to Learn Agile Development

140 Stories To Learn About Agile Software Development

11 Proven Solutions to Common GitHub Copilot Problems

10x Rockstar Ninja Wizard Vampires

10 Prioritization Techniques for Agile Product Development

10 Online Free Courses That Can Help to Learn Agile Development

140 Stories To Learn About Agile Software Development

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps