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 IV. RESULTS We first describe two elements of pair programming skill (Togetherness and Expediency) and then characterize three patterns of problematic behavior in pair programming sessions: (Getting Lost in the Weeds, Losing the Partner, and Drowning the Partner). We illustrate each pattern with excerpts from actual sessions. Togetherness Expediency Getting Lost in the Weeds Losing the Partner Drowning the Partner Section IV-E then gives examples of the alternate (high-skill) case, where pairs manage to avert these problems. A. Two Elements of Pair Programming Skill Togetherness. Good pairs manage to stay together, that is, to establish and maintain a shared mental model throughout their session. They detect and address relevant discrepancies in each other’s understanding of their task, work state, software system, and software development in general. Togetherness Expediency. Good pairs balance short-term goals, such as identifying a defect or implementing a new feature, and longterm goals, e.g., addressing any member’s knowledge gaps. 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