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 B. Anti-Pattern: Getting Lost in the Weeds Two developers may come up with more ideas on what to look up and how to proceed than a single developer. But pairs risk Getting Lost in the Weeds when they jump on too many of them with too little consideration. Such pairs may manage to Stay Together in that they both think about all these new ideas together, but they risk thinking too much about irrelevant details, losing track of what is important, and thus reduce their Expediency. Getting Lost in the Weeds Stay Together Expediency Example 1: Session DA2 (09:00–19:00). It is developer D4’s first week at the company, and he and D3 are tasked with implementing a new feature. D3 wants to explain the target state by showing a similar, already existing function. While D3 scrolls through the source code, D4 repeatedly interrupts him with questions unrelated to their task, and D3 always tries his best to provide all the information he can (highly compressed excerpt follows): Example 1: Session DA2 (09:00–19:00). D3: “In principle, there should be a toolbar up here [...] I’ll show you how it looked in the old calendar. [starts navigating in the source code]” D4: “[reading from screen] What are these navigation things for? Are these Actions? Where are they displayed?” D3: “[stops navigating] There is a—What’s it called again? [starts searching through package tree ...]” D4: “[later: reading from screen, chuckling] LicenseKey?” D3: “[stops searching] You’ll see that more often around here [...] let’s see where it’s used [starts fulltext search ...]” Since D4 is new at the company, providing him with information about the code base could be a good thing even if not pertinent to the current task. However, none of the side-topics actually led to D4 understanding something he did not already know (not shown above), so we characterize this as a case of a pair running into trouble (as defined in Section III-C). Instead, the main topic (i.e., explaining the target state to D4) is interrupted by twelve(!) abrupt topic changes (only two of which are shown above). Finishing an exchange with a net time of 30 seconds takes the pair about ten minutes—and it could have been even worse, as D3 was nearly lost after five minutes and only found his way back because a stacktrace happened to be displayed on-screen: could none D3: “OK. Now, where were we? [looks around, sees stacktrace on lower display corner] Ah, the exception, right.” 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.

Session

Avoid "Getting Lost in the Weeds" in Your Dev Pairings

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

11 Proven Solutions to Common GitHub Copilot Problems

Pair Programming: When Explanations Go Too Far

Avoiding The Pitfalls: How Good Pairs Overcome Problematic Behaviors

Unlocking the Skill: From Jelling to Flow in Pair Programming

Unlocking the Pair Programmer's Mind: The Core Elements of PP Skill

11 Proven Solutions to Common GitHub Copilot Problems

Pair Programming: When Explanations Go Too Far

Avoiding The Pitfalls: How Good Pairs Overcome Problematic Behaviors

Unlocking the Skill: From Jelling to Flow in Pair Programming

Unlocking the Pair Programmer's Mind: The Core Elements of PP Skill

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps