A place to cache linked articles (think custom and personal wayback machine)
Вы не можете выбрать более 25 тем Темы должны начинаться с буквы или цифры, могут содержать дефисы(-) и должны содержать не более 35 символов.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500
  1. <!doctype html><!-- This is a valid HTML5 document. -->
  2. <!-- Screen readers, SEO, extensions and so on. -->
  3. <html lang="fr">
  4. <!-- Has to be within the first 1024 bytes, hence before the <title>
  5. See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
  6. <meta charset="utf-8">
  7. <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
  8. <!-- The viewport meta is quite crowded and we are responsible for that.
  9. See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
  10. <meta name="viewport" content="width=device-width,initial-scale=1">
  11. <!-- Required to make a valid HTML5 document. -->
  12. <title>On Pair Programming (archive) — David Larlet</title>
  13. <meta name="description" content="Publication mise en cache pour en conserver une trace.">
  14. <!-- That good ol' feed, subscribe :). -->
  15. <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
  16. <!-- Generated from https://realfavicongenerator.net/ such a mess. -->
  17. <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
  18. <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
  19. <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
  20. <link rel="manifest" href="/static/david/icons2/site.webmanifest">
  21. <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
  22. <link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
  23. <meta name="msapplication-TileColor" content="#f0f0ea">
  24. <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
  25. <meta name="theme-color" content="#f0f0ea">
  26. <!-- Documented, feel free to shoot an email. -->
  27. <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
  28. <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
  29. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  30. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  31. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
  32. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  33. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  34. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  35. <script type="text/javascript">
  36. function toggleTheme(themeName) {
  37. document.documentElement.classList.toggle(
  38. 'forced-dark',
  39. themeName === 'dark'
  40. )
  41. document.documentElement.classList.toggle(
  42. 'forced-light',
  43. themeName === 'light'
  44. )
  45. }
  46. const selectedTheme = localStorage.getItem('theme')
  47. if (selectedTheme !== 'undefined') {
  48. toggleTheme(selectedTheme)
  49. }
  50. </script>
  51. <meta name="robots" content="noindex, nofollow">
  52. <meta content="origin-when-cross-origin" name="referrer">
  53. <!-- Canonical URL for SEO purposes -->
  54. <link rel="canonical" href="https://martinfowler.com/articles/on-pair-programming.html">
  55. <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">
  56. <article>
  57. <header>
  58. <h1>On Pair Programming</h1>
  59. </header>
  60. <nav>
  61. <p class="center">
  62. <a href="/david/" title="Aller à l’accueil">🏠</a> •
  63. <a href="https://martinfowler.com/articles/on-pair-programming.html" title="Lien vers le contenu original">Source originale</a>
  64. </p>
  65. </nav>
  66. <hr>
  67. <main>
  68. <blockquote>
  69. <p>Betty Snyder and I, from the beginning, were a pair. And I believe that
  70. the best programs and designs are done by pairs, because you can criticise
  71. each other, and find each others errors, and use the best ideas.</p>
  72. <p class="quote-attribution">-- <a href="http://www.computerhistory.org/revolution/birth-of-the-computer/4/78/2258">Jean Bartik, one of the very first programmers</a></p>
  73. </blockquote>
  74. <blockquote>
  75. <p>Write all production programs with two people sitting at one machine.</p>
  76. <p class="quote-attribution">-- <a href="https://www.amazon.com/gp/product/0321278658?ie=UTF8&amp;tag=martinfowlerc-20&amp;linkCode=as2&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0321278658">Kent Beck</a><img src="https://www.assoc-amazon.com/e/ir?t=martinfowlerc-20&amp;l=as2&amp;o=1&amp;a=0321601912" border="0" alt=""/></p>
  77. </blockquote>
  78. <p>Jean Bartik was one of the <a href="https://en.wikipedia.org/wiki/ENIAC#Programmers">ENIAC women</a>, who are considered by many to be the very first programmers.
  79. They took on the task of programming when the word "program" was not even used yet,
  80. and there were no role models or books to tell them how to do this - and they
  81. decided that it would be a good idea to work in a pair. It took about 50
  82. more years for pair programming to become a widespread term, when
  83. Kent Beck described the term in his book "Extreme Programming" in the late
  84. 1990s. The book introduced agile software development practices to a wider
  85. audience, pairing being one of them. </p>
  86. <p>Pair programming essentially means that two people write code together on one machine. It is a very collaborative way of working and involves a lot of communication. While a pair of developers
  87. work on a task together, they do not only write code, they also plan and discuss
  88. their work. They clarify ideas on the way, discuss approaches and come
  89. to better solutions.</p>
  90. <p>The first part of this article, <a href="#HowToPair">"How to
  91. pair"</a>, gives an overview of different practical approaches to pair
  92. programming. It's for readers who are looking to get started with pairing,
  93. or looking to get better at it.</p>
  94. <p>The second and third parts, <a href="#Benefits">"Benefits"</a>
  95. and <a href="#Challenges">"Challenges"</a>, dive deeper into
  96. what the goals of pair programming are, and how to deal with the challenges
  97. that can keep us from those goals. These parts are for you if you want to
  98. understand better why pair programming is good for your software and your
  99. team, or if you want some ideas what to improve.</p>
  100. <p>Part four and five, <a href="#ToPairOrNotToPair">"To pair or not
  101. to pair?"</a>, and <a href="#ButReallyWhyBother">"But really, why bother?"</a>,
  102. will conclude with our thoughts on pairing in the grand scheme of team flow
  103. and collaboration.</p>
  104. <section id="HowToPair">
  105. <h2>How to pair</h2>
  106. <section id="Styles">
  107. <h3>Styles</h3>
  108. <section id="DriverAndNavigator">
  109. <h4>Driver and Navigator</h4>
  110. <p>These classic pair programming role definitions can be applied in
  111. some way or other to many of the approaches to pairing.</p>
  112. <p>The <b>Driver</b> is the person at the wheel, i.e. the keyboard. She is
  113. focussed on completing the tiny goal at hand, ignoring larger issues
  114. for the moment. A driver should always talk through what she is doing
  115. while doing it.</p>
  116. <p>The <b>Navigator</b> is in the observer position, while the driver is
  117. typing. She reviews the code on-the-go, gives directions and shares
  118. thoughts. The navigator also has an eye on the larger issues, bugs,
  119. and makes notes of potential next steps or obstacles.</p>
  120. <p>The idea of this role division is to have two different
  121. perspectives on the code. The driver's thinking is supposed to be more
  122. tactical, thinking about the details, the lines of code at hand. The
  123. navigator can think more strategically in their observing role. They
  124. have the big picture in mind.</p>
  125. <p>A common flow goes like this:</p>
  126. <ul>
  127. <li>Start with a reasonably well-defined task</li>
  128. <li>Agree on one tiny goal at a time. This can be defined by a unit
  129. test, or by a commit message, or written on a sticky note.</li>
  130. <li>Switch keyboard and roles regularly. Shared active participation
  131. keeps the energy level up and we learn and understand things
  132. better.</li>
  133. <li>As navigator, avoid the "tactical" mode of thinking, leave the
  134. details of the coding to the driver - your job is to take a step back
  135. and complement your pair's more tactical mode with medium-term
  136. thinking. Park next steps, potential obstacles and ideas on sticky
  137. notes and discuss them after the tiny goal is done, so as not to
  138. interrupt the driver's flow.</li>
  139. </ul>
  140. </section>
  141. <section id="PingPong">
  142. <h4>Ping Pong</h4>
  143. <p>This technique embraces <a href="https://martinfowler.com/bliki/TestDrivenDevelopment.html">Test-Driven Development</a> (TDD)
  144. and is perfect when you have a clearly defined task that can be
  145. implemented in a test-driven way.</p>
  146. <ul>
  147. <li>"Ping": Developer A writes a failing test</li>
  148. <li>"Pong": Developer B writes the implementation to make it pass.</li>
  149. <li>Developer B then starts the next "Ping", i.e. the next failing
  150. test.</li>
  151. <li>Each "Pong" can also be followed by refactoring the code together,
  152. before you move on to the next failing test. This way you follow the
  153. "Red - Green - Refactor" approach: Write a failing test (red), make it
  154. pass with the minimum necessary means (green), and then <a href="https://martinfowler.com/tags/refactoring.html">
  155. refactor</a>.</li>
  156. </ul>
  157. </section>
  158. <section id="Strong-stylePairing">
  159. <h4>Strong-Style Pairing</h4>
  160. <p>This is a technique particularly useful for knowledge transfer,
  161. described in much more detail by Llewellyn Falco <a href="https://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html">here.</a></p>
  162. <p>The rule: "For an idea to go from your head into the computer it
  163. MUST go through someone else's hands". In this style, the navigator is
  164. usually the person much more experienced with the setup or task at
  165. hand, while the driver is a novice (with the language, the tool, the
  166. codebase, ...). The experienced person mostly stays in the navigator
  167. role and guides the novice.</p>
  168. <p>An important aspect of this is the idea that the driver totally
  169. trusts the navigator and should be "comfortable with incomplete
  170. understanding". Questions of "why", and challenges to the solution
  171. should be discussed after the implementation session. In a setting
  172. where one person is a total novice, this can make the pairing much
  173. more effective.</p>
  174. <p>While this technique borders on micro-management, it can be a
  175. useful onboarding tool to favor active "learning by doing" over
  176. passive "learning by watching". This style is great for initial
  177. knowledge transfer, but shouldn't be overused. Keep in mind that the
  178. goal is to be able to easily switch roles after some time, and ease
  179. out of the micro management mode. That will be a sign that the
  180. knowledge transfer worked.</p>
  181. </section>
  182. <section id="PairDevelopment">
  183. <h4>Pair Development</h4>
  184. <p>"Pair Development" is not so much a specific technique to pair, but
  185. more of a mindset to have about pairing. (We first came across the
  186. term in <a href="https://twitter.com/sarahmei/status/877738639991611392">this thread</a> on
  187. Sarah Mei's Twitter account.) The development of a <a href="https://martinfowler.com/bliki/UserStory.html">user story</a> or a
  188. feature usually requires not just coding, but many other tasks. As a
  189. pair, you're responsible for all of those things.</p>
  190. <p>To help get you into the mindset, the following are a few examples
  191. of the non-coding activities in a story life cycle that benefit from
  192. pairing.</p>
  193. <section id="">
  194. <p class="pairing-subheading">Planning - what's our goal?</p>
  195. <p>When you first start working on something together, don't jump
  196. immediately into the coding. This early stage of a feature's life
  197. cycle is a great opportunity to avoid waste. With four eyes on the
  198. problem this early on, catching misunderstandings or missing
  199. prerequisites can save you a lot of time later.</p>
  200. <ul>
  201. <li><b>Understand the problem:</b> Read through the story and play back to
  202. each other how you understand it. Clear up open questions or potential
  203. misunderstandings with the Product Owner. If you have a
  204. <a href="https://www.agilealliance.org/glossary/definition-of-ready/">Definition of Ready</a> in your
  205. team, go through that again and make sure you have everything to get
  206. started.
  207. </li>
  208. <li><b>Come up with a solution:</b> Brainstorm what potential solutions for
  209. the problem are. You can either do this together, or split up and then
  210. present your ideas to each other. This depends on how well-defined the
  211. solution already is, but also on your individual styles. Some people
  212. like some time to think by themselves, others like talking things
  213. through out loud while they are thinking. If one of you is less
  214. familiar with the domain or tech, take some time to share the
  215. necessary context with each other.
  216. </li>
  217. <li><b>Plan your approach:</b> For the solution you chose, what are the steps
  218. you need to take to get there? Is there a specific order of tasks to
  219. keep in mind? How will you test this? Ideally, write these steps down,
  220. in a shared document or on sticky notes. That will help you keep track
  221. of your progress, or when you need to onboard somebody else to help work on the task. Writing this down also simply helps remember
  222. what needs to be done - in the moment, we too often underestimate how
  223. many things we will have forgotten even as quickly as the next
  224. day...
  225. </li>
  226. </ul>
  227. </section>
  228. <section id="">
  229. <p class="pairing-subheading">Research and explore</p>
  230. <p>When implementing a feature that requires you to use a technology
  231. you are both unfamiliar with, you'll have to do some research and
  232. exploration first. This work does not fit into the clean-cut
  233. "driver-navigator" or "ping-pong" approaches. E.g., browsing search
  234. engine results together on the same screen is usually not very
  235. effective.</p>
  236. <p>Here is one way to approach this in pair development mode:</p>
  237. <ul>
  238. <li>Define a list of questions that you need to answer in order to come
  239. up with a suitable solution.</li>
  240. <li>Split up - either divide the questions
  241. among you, or try to find answers for the same questions separately.
  242. Search the internet or other resources within your organisation to
  243. answer a question, or read up on a concept that is new to both of
  244. you.</li>
  245. <li>Get back together after a previously agreed upon timebox and
  246. discuss and share what you have found.</li>
  247. </ul>
  248. </section>
  249. <section id="">
  250. <p class="pairing-subheading">Documentation</p>
  251. <p>Another thing to work on together beyond the code is documentation.
  252. Reflect together if there is any documentation necessary for what
  253. you've done. Again, depending on the case at hand and your individual
  254. preferences, you can either create the documentation together, or have
  255. one of you create it, then the other review and word-smith.</p>
  256. <p>Documentation is a great example of a task where a pair can
  257. keep each other disciplined. It's often a task left for
  258. last, and when it's the last thing keeping us from the great feeling
  259. of putting our story into "Done", then more often than not, we skip
  260. it, or "wing it". Working in a pair keeps us honest about some of the
  261. valuable, but annoying things that we'll be very thankful for in the
  262. future.</p>
  263. </section>
  264. </section>
  265. </section>
  266. <section id="TimeManagement">
  267. <h3>Time management</h3>
  268. <p>In addition to the general styles for pairing, there are other little tools and techniques to make it easier.</p>
  269. <p>The pomodoro technique is ones of those tools. It is a time management method that breaks work
  270. down into chunks of time - traditionally 25 minutes - that are
  271. separated by short breaks. The technique can be applied to almost all
  272. of the pairing approaches described and will keep you focused. Pairing
  273. can be an exhausting practice, so it is helpful to get a reminder to
  274. take breaks and to switch the keyboard regularly.</p>
  275. <p>Here is an example of how using the pomodoro technique looks like
  276. in practice.</p>
  277. <ul>
  278. <li>Decide on what to work on next</li>
  279. <li>Set a timer for 25 minutes, e.g. with the help of the many pomodoro
  280. browser extensions - or even a real life tomato shaped kitchen
  281. timer...</li>
  282. <li>Do some work without interruptions</li>
  283. <li>Pause work when the timer rings - start with short breaks (5-10
  284. minutes)</li>
  285. <li>After 3 or 4 of these "pomodoros", take a longer break (15–30 minutes)</li>
  286. <li>Use the short breaks to <i>really</i> take a break and tank energy, get some water or
  287. coffee, use the bathroom, get some fresh air. Avoid using these short
  288. breaks for other work, like writing emails.</li>
  289. </ul>
  290. </section>
  291. <section id="PairRotations">
  292. <h3>Pair Rotations</h3>
  293. <p>Rotating pairs means that after working together for some time, one
  294. half of the pair leaves the story, while the other person onboards
  295. somebody new to continue. The person who stays is often called the
  296. "anchor" of a story.</p>
  297. <p>One category of reasons why to rotate is logistics. Your pairing
  298. partner could be sick or going on holiday. Or one of you is working
  299. remotely for a day, and the work requires physical presence on site, e.g.
  300. because there is a hardware setup involved.</p>
  301. <p>Another group of reasons why to rotate is to mix things up. Either
  302. the two of you have been working together for a while and are starting
  303. to show signs of "cabin fever" because you are spending too much time
  304. together. Or you're working on something very tedious and
  305. energy-draining - a rotation will give one of you a break, and a new
  306. person can bring in some fresh perspectives and energy.</p>
  307. <p>Finally, the most given reason for pair rotations is to avoid
  308. knowledge silos, increase collective code ownership, and get some more code
  309. review on-the-go. Pairing itself is already helping with those things,
  310. but rotations can further increase the average number of eyes on each
  311. line of code that goes to production.</p>
  312. <p>As to the ideal frequency of rotations, this is where opinions
  313. diverge. Some people believe that rotations every 2-3 days are crucial
  314. to ensure a sufficient knowledge spread and quality. Every rotation
  315. comes with some costs though. There's the time to onboard a new
  316. person, and the cost of a context switch for one of the two. If there
  317. is no constant anchor for continuity, the risk increases that tacit
  318. knowledge about the problem and solution space gets lost and triggers
  319. rework. For more junior developers it's sometimes more beneficial to
  320. stay on something for longer, so they have sufficient time to immerse
  321. themselves in a topic and give new knowledge time to settle.</p>
  322. <p>Think about the trade off between these costs and the benefits. For
  323. example, let's say you have high quality knowledge sharing already,
  324. with team "show and tells", readable code and good documentation. In
  325. that case, maybe an insistence on frequent rotations only marginally
  326. improves your collective code ownership, while creating high amounts
  327. of friction and overhead.</p>
  328. </section>
  329. <section id="PlanTheDay">
  330. <h3>Plan the Day</h3>
  331. <p>Pairing requires a certain level of scheduling and calendar
  332. coordination. If you don't take time to acknowledge and accommodate
  333. this, it will come back to haunt you later in the day.</p>
  334. <p>Start the day with a calendar check - agree with your pairing
  335. partner on how many hours you are going to pair, and see if you need
  336. to plan around meetings or time needed to work on other things outside
  337. of the pairing task. If it turns out that one of you will have to work
  338. by themselves for a while, then make sure to prepare for things to
  339. continue without the other person, e.g. by not using that person's
  340. computer to code.</p>
  341. <p>If you have meetings or other commitments during the day, make sure
  342. you have a reminder in place that you will notice, especially when
  343. working on your pairing partner's machine. If your team pairs by
  344. default, consider agreeing on regular "core coding hours" for
  345. everyone. This makes scheduling much easier.</p>
  346. </section>
  347. <section id="PhysicalSetup">
  348. <h3>Physical Setup</h3>
  349. <p>Pair programming means you need to work very closely together in
  350. the physical space of one shared desk. This is quite different from
  351. having your own table to spread out on. Being that close to one
  352. another requires a certain level of respect and attention for each
  353. other's needs. That is why it is worth spending some time figuring out
  354. a comfortable setup for both of you.</p>
  355. <ul>
  356. <li>Make sure both of you have enough space, clear up the desk if
  357. necessary.</li>
  358. <li>Is there enough space for both chairs in front of the desk? Get
  359. waste bins and backpacks out of the way.</li>
  360. <li>Do you want to use two keyboards or one? Same for the mouse, one or
  361. two? There's no clear rule that always works, we recommend you try out
  362. what works best for each situation. Some of the factors that play into
  363. this are hygiene, how good you are at sharing keyboard time, or how
  364. much space you have available.</li>
  365. <li>Do you have an external monitor available, or maybe even two? If
  366. not, you can also consider setting up some kind of screen sharing, as
  367. if you were remote pairing. In that setup, each of you would use their
  368. own laptop keyboards.</li>
  369. <li>Check with your partner if they have any particular preferences or
  370. needs (e.g. larger font size, higher contrast, ...)</li>
  371. <li>If you have an unusual keyboard/IDE setup check with your partner
  372. if they are okay with it. See if you can have a simple mechanism to
  373. switch your settings back to a more standard configuration for these
  374. situations.</li>
  375. </ul>
  376. <p>It is beneficial if your team can agree on a default setup, so that
  377. you don't have to discuss these things again and again.</p>
  378. </section>
  379. <section id="RemotePairing">
  380. <h3>Remote Pairing</h3>
  381. <p>Are you part of a distributed team, or some team members
  382. occasionally work from home? You can still practice pair programming, as long as both of you have reasonably stable internet access.</p>
  383. <section id="">
  384. <p class="pairing-subheading">The Setup</p>
  385. <p>For remote pairing, you need a screen-sharing solution that allows you to
  386. not only see, but also control the other person's machine, so that you are
  387. able to switch the keyboard. Many video conferencing tools today already
  388. support this, so if you're working at a company who has a license for a
  389. commercial VC tool, try that first. There are also open source tools for video
  390. calls with remote control, e.g. <a href="https://jitsi.org">jitsi</a>. For solutions
  391. that work at lower bandwidths, try things like <a href="https://www.hamvocke.com/blog/remote-pair-programming-with-tmux/">
  392. ssh with tmux</a> or the <a href="https://visualstudio.microsoft.com/services/live-share/">Live Share
  393. extension for Visual Studio Code</a>.</p>
  394. </section>
  395. <section id="">
  396. <p class="pairing-subheading">Tips</p>
  397. <ul>
  398. <li><b>Use video:</b> Since people communicate a lot through gestures and facial
  399. expressions it is nice to see the shared screen and your
  400. pairing partner's video at the same time. Some video conference solutions come with this feature; if yours doesn't, consider opening up an additional call in order to see each other. </li>
  401. <li><b>Planning and designing:</b> Use collaborative online visualization tools, to reproduce
  402. the experience of sketching out things on paper or a whiteboard.</li>
  403. <li><b>Audio experience:</b> Look for a quiet area and use a good headset, maybe even
  404. with a directional microphone. If you can't get away from the noise, "push to
  405. speak" functionality can also help. To avoid distractions on your side,
  406. noise-cancelling headphones are your friend.</li>
  407. <li>Dealing with network lag: It can be exhausting to work on a remote computer
  408. for a longer period of time when there is a network lag. So make sure to
  409. switch computers regularly, so that each of you has a chance to work on their
  410. own machine without lag. A network lag can also be annoying when you scroll
  411. through files because it can be hard to follow. It helps to avoid scrolling in
  412. long files, try to use keyboard shortcuts to open different parts of the file
  413. or use the collapse/uncollapse functionality instead.</li>
  414. </ul>
  415. </section>
  416. <section id="">
  417. <p class="pairing-subheading">The Human Part</p>
  418. <p>If you work in a setup where not the whole team is distributed and just one
  419. or a few of you are remote, try to include the remote partner in all
  420. discussions that are happening in the office. We tend to forget how much we
  421. share incidentally just by sitting in the same room.</p>
  422. <p>Working remotely with someone you haven't met and do not know creates an
  423. additional challenge. On the one hand, pairing is a chance to get closer to each
  424. other on a remote team. On the other hand, it's sometimes easy to forget that
  425. part of the collaboration. If there is no chance that you meet in person, think about other ways
  426. to get to know each other a bit better, e.g. try to have a remote coffee
  427. together.</p>
  428. <p>Finally, while remote pairing can have its challenges, it can also make it easier to focus than when pairing on site, because it
  429. is easier to blend out distractions with headphones on.</p>
  430. </section>
  431. </section>
  432. <section id="HaveADonutTogether">
  433. <h3>Have a Donut Together</h3>
  434. <p>Celebrate when you have accomplished a task together! High-fiving
  435. each other might seem corny, but it's actually a little "power pose"
  436. you can do together that can energize and get you ready for the next
  437. task. Or maybe you create your own way of celebrating success, like
  438. Lara Hogan, who celebrates career achievements with a <a href="https://larahogan.me/donuts/">
  439. donut</a>.</p>
  440. </section>
  441. <section id="ThingsToAvoid">
  442. <h3>Things to Avoid</h3>
  443. <p>The different approaches and techniques help you to have a
  444. better pairing experience. Here are a few common pitfalls to avoid:</p>
  445. <section id="">
  446. <p class="pairing-subheading">Drifting apart</p>
  447. <p>When you pair, avoid to read emails or to use your phone. These distractions might come across
  448. as direspectful to your pair, and they distract you from the task you are working on.
  449. If you really need to check
  450. something, make it transparent what you are doing, and why. Make sure that everyone has
  451. enough time to read their emails by taking enough breaks and reserving some
  452. individual time each day.</p>
  453. </section>
  454. <section id="">
  455. <p class="pairing-subheading">Micro-Management Mode</p>
  456. <p>Watch out for micro-management mode: It doesn't leave room for
  457. the other person to think and is a frustrating experience, if
  458. someone keeps giving you instructions like:</p>
  459. <ul>
  460. <li>"Now type 'System, dot, print, "...</li>
  461. <li>"Now we need to create a new class called..."</li>
  462. <li>"Press command shift O..."</li>
  463. </ul>
  464. </section>
  465. <section id="">
  466. <p class="pairing-subheading">Impatience</p>
  467. <p>Apply the "5 seconds rule": When the navigator sees the driver do
  468. something "wrong" and wants to comment, wait at least 5 seconds
  469. before you say something - the driver might already have it in mind,
  470. then you are needlessly interrupting their flow.</p>
  471. <p>As Navigator, don't immediately point out any error or upcoming
  472. obstacle: Wait a bit for the driver to correct or write a sticky
  473. note to remember later. If you intervene immediately, this can be
  474. disruptive to the driver's thinking process.</p>
  475. </section>
  476. <section id="">
  477. <p class="pairing-subheading">Keyboard Hogging</p>
  478. <p>Watch out if you're "hogging the keyboard": Are you controlling
  479. it all the time, not letting your pairing partner do some typing as well?</p>
  480. <p>This can be a really annoying experience for your pair and might cause them having
  481. a hard time focussing because of limited "active participation". Try
  482. one of the approaches described earlier to make sure that you switch
  483. the keyboard frequently.</p>
  484. </section>
  485. <section id="">
  486. <p class="pairing-subheading">Pairing 8 Hours per Day</p>
  487. <p>Teams that are really committed to making pair programming work
  488. sometimes end up pairing for 8 hours a day. In our experience, that
  489. is not sustainable. First of all it is just too exhausting. And
  490. secondly, it does not even work in practice because there are so
  491. many other things you do other than coding, e.g. checking emails,
  492. having 1:1s, going to meetings, researching/learning. So keep that
  493. in mind when planning your day and don't assume it will be 100%
  494. coding together.</p>
  495. </section>
  496. </section>
  497. <section id="ThereIsNottheRightWay">
  498. <h3>There is not "THE" right way</h3>
  499. <p>There are many approaches to pair programming and there is not
  500. "THE" right way to do it. It depends on your styles, personalities,
  501. experience, the situation, the task and many other factors. In the
  502. end, the most important question is: Do you get the promised benefits
  503. out of it? If this is not the case, try out something else, reflect,
  504. discuss and adjust to get them.</p>
  505. </section>
  506. </section>
  507. <section id="Benefits">
  508. <h2>Benefits</h2>
  509. <p>What is pair programming good for? Awareness of all its potential
  510. benefits is important to decide when you do it, how to do it well, and to
  511. motivate yourself to do it in challenging times. The main goals pairing
  512. can support you with are software quality and team flow.</p>
  513. <p>How can pairing help you achieve those goals then?</p>
  514. <section id="KnowledgeSharing">
  515. <h3>Knowledge Sharing</h3>
  516. <p>Let's start with the most obvious and least disputed benefit of
  517. pairing: Knowledge sharing. Having two people work on a piece of the
  518. code helps the team spread knowledge on technology and domain on a daily
  519. basis and prevents silos of knowledge. Moreover, when two minds
  520. understand and discuss a problem, we improve the chances of finding a
  521. good solution. Different experiences and perspectives will lead to the
  522. consideration of more alternatives. </p>
  523. <section id="">
  524. <p class="pairing-subheading">Practical Tips</p>
  525. <p>Don't shy away from pairing on tasks when you have no idea about
  526. the technology involved, or the domain. If you keep working in the
  527. area that you feel most comfortable in, you will miss out on learning
  528. new things, and ultimately spreading
  529. knowledge in your team.</p>
  530. <p>If you notice that a team member tends
  531. to work on the same topics all the time, ask them to mix it up to
  532. spread their expertise. It can also help to create a skill matrix with
  533. the team's tech &amp; business topics and each person's strengths and
  534. gaps in each area. If you put that on a wall in your team area, you
  535. can work together on getting a good spread of knowledge.</p>
  536. </section>
  537. </section>
  538. <section id="Reflection">
  539. <h3>Reflection</h3>
  540. <p>Pair programming forces us to discuss approaches and solutions,
  541. instead of only thinking them through in our own head. Saying and
  542. explaining things out loud pushes us to reflect if we really have the
  543. right understanding, or if we really have a good solution. This not only
  544. applies to the code and the technical design, but also to the user story
  545. and to the value a story brings.</p>
  546. <section id="">
  547. <p class="pairing-subheading">Practical Tips</p>
  548. <p>It requires trust between the two of you to create an atmosphere in
  549. which both of you feel free to ask questions and also speak openly
  550. about things you don't understand. That's why building relationships
  551. within the team becomes even more important when you pair. Take time
  552. for regular 1:1 and feedback sessions.</p>
  553. </section>
  554. </section>
  555. <section id="KeepingFocus">
  556. <h3>Keeping focus</h3>
  557. <p>It's a lot easier to have a structured approach when there are two of
  558. you: Each of you has to explicitly communicate why you are doing
  559. something and where you are heading. When working solo, you can get
  560. distracted a lot easier, e.g. by "just quickly" trying a different
  561. approach without thinking it through, and then coming back out of the
  562. rabbit hole hours later. Your pairing partner can prevent you from
  563. going down those rabbit holes and focus on what is important to finish
  564. your task or story. You can help each other stay on track.</p>
  565. <section id="">
  566. <p class="pairing-subheading">Practical Tips</p>
  567. <p>Make plans together! Discuss your task at hand and think about
  568. which steps you need to make to reach your goal. Put each of the steps
  569. on sticky notes (or if remotely, subtasks in your ticket management
  570. system), bring them in order and go one by one. Try this in
  571. combination with the <a href="#TimeManagement">Pomodoro technique</a> and try to finish one of the goals in one pomodoro.</p>
  572. <p>Never forget that communication is key. Talk about what you are
  573. doing and demand explanations from each other.</p>
  574. </section>
  575. </section>
  576. <section id="CodeReviewOn-the-go">
  577. <h3>Code review on-the-go</h3>
  578. <p>When we pair, we have 4 eyes on the little and the bigger things as
  579. we go, more errors will get caught on the way instead of after we're
  580. finished.</p>
  581. <p>The <a href="https://martinfowler.com/tags/refactoring.html">refactoring</a> of code is always part of coding, and therefore of pair
  582. programming. It's easier to improve code when you have someone beside
  583. you because you can discuss approaches or the naming of things for
  584. example.</p>
  585. <p>Doing code reviews after the fact has some downsides. We will dive
  586. more into this later, in <a href="#ToPairOrNotToPair">"To pair or
  587. not to pair?"</a>.</p>
  588. <section id="">
  589. <p class="pairing-subheading">Practical Tips</p>
  590. <p>Ask each other questions! Questions are the most powerful tool to
  591. understand what you are doing and to come to better solutions. If code
  592. is not easy to read and understand for one of you, try a different way
  593. that is easier to understand.</p>
  594. <p>If you feel the need to have more code review on pair programmed
  595. code, reflect if you can improve your pairing. Weren't you able to
  596. raise all questions and concerns during your pairing session? Why is
  597. that? What do you need to change?</p>
  598. </section>
  599. </section>
  600. <section id="TwoModesOfThinkingCombined">
  601. <h3>Two modes of thinking combined</h3>
  602. <p>As mentioned when we described the classic
  603. <a href="#DriverAndNavigator">driver/navigator</a> style
  604. earlier, pairing allows you to have different perspectives on the code.
  605. The driver's brain is usually more in "tactical" mode, thinking about
  606. the details, the current line of code. Meanwhile, the navigator's brain
  607. can think more strategically, consider the big picture, park next steps
  608. and ideas on sticky notes. Could one person combine these two modes of
  609. thinking? Probably not! Having a tactical and strategic view combined
  610. will increase your code quality because it will allow you to pay
  611. attention to the details while also having the bigger picture in
  612. mind.</p>
  613. <section id="">
  614. <p class="pairing-subheading">Practical Tips</p>
  615. <p>Remember to switch the keyboard and thus the roles regularly. This
  616. helps you to refresh, to not get bored, and to practice both ways of
  617. thinking.</p>
  618. <p>As navigator, avoid the "tactical" mode of thinking, leave the
  619. details of the coding to the driver - your job is to take a step back
  620. and complement your pair's more tactical mode with medium-term
  621. thinking.</p>
  622. </section>
  623. </section>
  624. <section id="CollectiveCodeOwnership">
  625. <h3>Collective Code Ownership</h3>
  626. <blockquote>
  627. <p>Collective code ownership abandons any notion of individual
  628. ownership of modules. The code base is owned by the entire team and
  629. anyone may make changes anywhere.</p>
  630. <p class="quote-attribution">-- <a href="https://www.martinfowler.com/bliki/CodeOwnership.html">Martin Fowler</a></p>
  631. </blockquote>
  632. <p>Consistent pairing makes sure that every line of code was touched or
  633. seen by at least 2 people. This increases the chances that anyone on the
  634. team feels comfortable changing the code almost anywhere. It also makes
  635. the codebase more consistent than it would be with single coders
  636. only.</p>
  637. <section id="">
  638. <p class="pairing-subheading">Practical Tips</p>
  639. <p>Pair programming alone does not guarantee you achieve collective
  640. code ownership. You need to make sure that you also rotate people
  641. through different pairs and areas of the code, to prevent knowledge
  642. silos.</p>
  643. </section>
  644. </section>
  645. <section id="KeepsTheTeamsWipLow">
  646. <h3>Keeps the team's WIP low</h3>
  647. <p>Limiting work in progress is one of the core principles of Kanban to
  648. improve team flow. Having a <a href="https://dzone.com/articles/the-importance-of-wip-limits">Work in Progress (WIP)
  649. limit</a> helps your team focus on the most important tasks. Overall
  650. team productivity often increases if the team has a WIP limit in place,
  651. because multi-tasking is not just inefficient on an individual, but also on the team level.
  652. Especially in larger teams, pair programming limits the number of things
  653. a team can work on in parallel, and therefore increases the overall
  654. focus. This will ensure that work constantly flows, and that blockers are
  655. addressed immediately.</p>
  656. <section id="">
  657. <p class="pairing-subheading">Practical Tips</p>
  658. <p>Limit your team's WIP to the number of developer pairs on your team
  659. and make it visible in your team space (or, if you work remotely, in your
  660. online project management tool). Have an eye on the limit before picking up
  661. new tasks. WIP limit discipline might naturally force you into a
  662. pairing habit.</p>
  663. </section>
  664. </section>
  665. <section id="FastOnboardingOfNewTeamMembers">
  666. <h3>Fast onboarding of new team members</h3>
  667. <p>Since pairing facilitates knowledge sharing it can help with the
  668. onboarding of new team members. New joiners can get to know the project,
  669. the business and the organisation with the help of their pair. Changes
  670. in a team have an impact on the team flow. People just need some time to
  671. get to know each other. Pair programming can help to minimize that
  672. impact, because it forces people to communicate a lot more than they
  673. need when working solo.</p>
  674. <section id="">
  675. <p class="pairing-subheading">Practical Tips</p>
  676. <p>It is not enough to just put new joiners into a pair, and then they
  677. are "magically" included and onboarded. Make sure to provide the big
  678. picture and broader context before their first pairing session, and
  679. reserve some extra time for the onboarding. This will make it easier
  680. for them to follow along and contribute during the pairing, and get
  681. the most out of it. Always use the new joiners' machine when pairing, to make sure that
  682. they are set up to work by themselves as well.</p>
  683. <p>Have an onboarding plan with a list of topics to cover. For some topics you might want to schedule dedicated sessions, for other topics the new
  684. team member can take the onboarding plan with her from pair to pair. If something is covered in
  685. the pairing session, you can check it off the list. This way
  686. the onboarding progress is visible to everyone on the team. </p>
  687. </section>
  688. </section>
  689. </section>
  690. <section id="Challenges">
  691. <h2>Challenges</h2>
  692. <p>While pair programming has a lot of benefits, it also requires practice and
  693. might not work smoothly from the start. The following is a list of some of the common challenges teams
  694. experience, and some suggestions on how to cope with them. When you come across
  695. these challenges, keep the benefits in mind and remember why you pair.
  696. It is important to know what you want to achieve with a practice, so that
  697. you can adjust the way you do it.</p>
  698. <section id="PairingCanBeExhausting">
  699. <h3>Pairing can be exhausting</h3>
  700. <p>When working alone, you can take breaks whenever you want, and your mind
  701. can drift off or shut down for a bit when it needs to. Pairing forces
  702. you to keep focus for potentially longer stretches of time, and find common ground
  703. with the other person's rhythm and ways of thinking. The increased focus
  704. is one of the benefits of pairing, but can also make it quite intense and
  705. exhausting.</p>
  706. <section id="">
  707. <p class="pairing-subheading">Ways to tackle</p>
  708. <p>Taking enough breaks is key to face this challenge. If you notice
  709. you are forgetting to take regular breaks, try scheduling them with an
  710. alarm clock, for example 10 minutes per hour. Or use a time management
  711. technique like <a href="#TimeManagement">Pomodoro</a>.
  712. Don't skip your lunch break: Get away from
  713. the monitor and take a real break. Pairing or not, taking breaks is
  714. important and increases productivity.</p>
  715. <p>Another important thing to prevent exhaustion is to not pair 8
  716. hours per day. Limit it to a maximum of 6 hours per day. Regularly
  717. switching roles from driver to navigator can also help to keep the
  718. energy level up.</p>
  719. </section>
  720. </section>
  721. <section id="IntenseCollaborationCanBeHard">
  722. <h3>Intense collaboration can be hard</h3>
  723. <p>Working so closely with another person for long stretches of time is
  724. intense. You need to communicate constantly and it requires empathy and
  725. interpersonal skills.</p>
  726. <p>You might have
  727. differences in techniques, knowledge, skills, extraversion,
  728. personalities, or approaches to problem-solving. Some combinations of those might
  729. not match well and give you a rocky start. In that case, you need to invest some time to
  730. improve collaboration, and make it a mutual learning experience instead of
  731. a struggle.</p>
  732. <section id="">
  733. <p class="pairing-subheading">Ways to tackle</p>
  734. <p>A conversation at the beginning of your pairing session can help
  735. you to understand differences between your styles, and plan to adapt
  736. to that. Start your first session with questions like "How do we want
  737. to work together?", "How do you prefer to pair?". Be aware of how you
  738. like to work and how you are efficient, but also don't be closed off
  739. to other approaches - maybe you'll discover something new. </p>
  740. <p>At the end of a day of pairing, do a round of feedback for each
  741. other. If the idea of giving feedback seems daunting to you, think
  742. about it more as a mini retrospective. Reflect on how you both felt
  743. during the pairing session. Were you alert? Were you tired? What made
  744. you feel comfortable, what not? Did you switch the keyboard often
  745. enough? Did you achieve your goals? Is there anything you would like
  746. to try next time? It's good to make this a routine early on, so you have
  747. practice in giving feedback when something goes wrong. </p>
  748. <p>There are excellent trainings and <a href="https://www.penguinrandomhouse.com/books/331191/difficult-conversations-by-douglas-stone-bruce-patton-and-sheila-heen/9780143118442/">
  749. books</a> that can help you deal with interpersonal conflicts and
  750. difficulties, for example on difficult conversations.</p>
  751. <p>Face the challenges as a team and don't leave conflicts to
  752. individuals. You can do this for example by organising a session on
  753. pairing in which you discuss how to deal with difficulties together.
  754. Start the session by collecting the benefits of pairing, so that you
  755. know what you all want to get out of it. Afterwards collect the
  756. challenges each individual feels when pairing. Now the group can think
  757. about which actions might help to improve. You could also collect the
  758. hot button triggers of the team members: What makes you immediately
  759. feel uncomfortable when pairing?</p>
  760. </section>
  761. </section>
  762. <section id="InterruptionsByMeetings">
  763. <h3>Interruptions by meetings</h3>
  764. <p>Have you ever had days full of meetings, and you get the impression
  765. you are not getting anything done? This probably happens in every
  766. delivery team. Meetings are necessary to discuss, plan and agree on
  767. things you are going to build, but on the other hand they interrupt the
  768. flow. When a team practices pair programming the effect of too many
  769. meetings can get even worse. If each of the persons pairing
  770. has meetings at different times, the interruptions are multiplied.</p>
  771. <section id="">
  772. <p class="pairing-subheading">Ways to tackle</p>
  773. <p>One approach is to limit the time slots in which meetings happen,
  774. for example by defining core pairing hours without meetings, or by
  775. blocking out no-meeting-times with rules like "no meetings after noon".</p>
  776. <p>It is also worth thinking about meeting length and overall amount.
  777. Which meetings do you really need? What goals do they have and how can
  778. you improve their quality, for example with proper preparation,
  779. facilitation, and a clear agenda.</p>
  780. <p>But one thing is for sure: There will always be meetings. So how to
  781. deal with that as a pair? Check your calendars together at the
  782. beginning of your pairing session, make sure you have enough time to
  783. start pairing at all. If you have any meetings consider attending them
  784. as a pair. Rely on your Product Owner, or other non-pairing team
  785. members, to keep interruptions away from the team in the core pairing
  786. hours.</p>
  787. </section>
  788. </section>
  789. <section id="DifferentSkillLevels">
  790. <h3>Different skill levels</h3>
  791. <p>When two people with different experience levels pair on a topic,
  792. this often leads to false assumptions on how much each of them can
  793. contribute, or frustrations because of difference in pace.</p>
  794. <section id="">
  795. <p class="pairing-subheading">Ways to tackle</p>
  796. <p>If your pair has more experience on the topic: Don't assume they
  797. know best. Maybe the need to explain why they are doing things the way they are
  798. will bring them new insights. Asking questions on
  799. the how and why can lead to fruitful discussions and better solutions.
  800. </p>
  801. <p>If your pair has less experience on the topic: Don't assume they
  802. cannot contribute much to the solution. You might be stuck wearing
  803. blinders and a different viewpoint can help you to come to a better
  804. solution. Also, remember that having to explain a concept is a great
  805. opportunity to test if you've really understood it and thought it all
  806. the way through.</p>
  807. <p>It also helps to be aware of different learning stages to
  808. understand how the learning process from novice to expert works. Dan
  809. North has described this very nicely in his talk <a href="https://www.youtube.com/watch?v=lvs7VEsQzKY">Patterns of Effective Teams</a>.
  810. He introduces the <a href="https://apps.dtic.mil/dtic/tr/fulltext/u2/a084551.pdf">Dreyfus Model of Skills
  811. Acquisition</a> as a way to understand the different stages of learning,
  812. and what combining them means in the context of pairing.</p>
  813. </section>
  814. </section>
  815. <section id="PowerDynamics">
  816. <h3>Power Dynamics</h3>
  817. <p>Dealing with power dynamics is probably one of the hardest challenges
  818. in this list. Pair programming does not happen in a space without
  819. hierarchies. There are formal hierarchies, for example between a manager
  820. and their report, and informal ones. Examples for informal hierarchies
  821. are:</p>
  822. <ul>
  823. <li>junior - senior</li>
  824. <li>non-men - men</li>
  825. <li>career changers - folks with a CS degree</li>
  826. <li>People of color - white folks</li>
  827. </ul>
  828. <p>And these are just a few. Power dynamics are fluid and
  829. intersectional. When two people pair, multiple of those dynamics can be
  830. in play and overlap. To get an idea of how power imbalance can impact
  831. pairing, here are a few examples. </p>
  832. <ul>
  833. <li>One person is dominating the pairing session by hogging the keyboard
  834. and not giving room to their pairing partner.</li>
  835. <li>One person stays in a teaching position and attitude all the
  836. time.</li>
  837. <li>One person is not listening to the other one, and dismissing their
  838. suggestions.</li>
  839. </ul>
  840. <p>It sometimes can be subtle to tie these situations back to
  841. hierarchies, you often just think that you don't get along with each
  842. other. But the underlying issue is often times influenced by an
  843. imbalance between the two folks pairing. </p>
  844. <p>Sarah Mei has written an <a href="https://twitter.com/sarahmei/status/991001357455835136">excellent
  845. series of tweets</a> on the topic and has also given a talk that
  846. covers <a href="https://www.youtube.com/watch?v=YL-6RCTywbc">power dynamics in agile</a> in
  847. a more general way.</p>
  848. <section id="">
  849. <p class="pairing-subheading">Ways to tackle</p>
  850. <p>The first step to tackle this is for the person on the upward side
  851. of the power dynamic to acknowledge and admit to themselves their
  852. position. Only then can you honestly reflect on interactions you have
  853. with your pairing partner, and how power dynamics impact them. Try to
  854. think about your own positionality and situatedness. What can you
  855. actively do to neutralize power imbalance?</p>
  856. <p>Recognizing these types of differences and adapting our behaviour
  857. to improve collaboration can be hard. It requires a lot of self
  858. reflection. There are trainings that can help individuals or teams
  859. with this, for example "anti-bias" or <a href="https://frameshiftconsulting.com/ally-skills-workshop/">
  860. ally skills</a> trainings.</p>
  861. </section>
  862. </section>
  863. <section id="PairingWithLotsOfUnknowns">
  864. <h3>Pairing with lots of Unknowns</h3>
  865. <p>When you work on a large topic where both of you don't have an idea
  866. how to solve a problem, the usual pairing styles often don't work as well.
  867. Let's say you need to use a technology for the first time, or try out a new approach or pattern.
  868. Researching and experimenting together works in some constellations,
  869. but it can also be frustrating because
  870. we all have different approaches to figuring out how things work, and we read
  871. and learn at different paces.</p>
  872. <section id="">
  873. <p class="pairing-subheading">Ways to tackle</p>
  874. <p>When there are lots of unknowns, e.g. you work with a new
  875. technology, think about doing a <a href="https://en.wikipedia.org/wiki/Spike_(software_development)">
  876. spike</a> to explore the topic and learn
  877. about the technology before you actually start working. Don't forget
  878. to share your findings with the team, maybe you have a knowledge
  879. exchange session and draw some diagrams you can put up in the team
  880. space.</p>
  881. <p>In these situations, remember to take on the mindset of <a href="#PairDevelopment">pair development</a>, as opposed to pair <i>programming</i>. It's okay to split up to do research - maybe after agreeing on the set of questions you need to answer together.</p>
  882. </section>
  883. </section>
  884. <section id="NoTimeForYourself">
  885. <h3>No time for yourself</h3>
  886. <p>We've talked about how being in a constant conversation with each other can be pretty energy draining. Most people also need some time on their own throughout the day. That is especially true
  887. for more <a href="https://www.ted.com/talks/susan_cain_the_power_of_introverts?language=en">introverted folks</a>.</p>
  888. <p>When working solo, we quite naturally take time to dig into a topic or learn when
  889. we need to. But that can feel like an interruption in pairing. So how can you take that alone and
  890. learning time when needed?</p>
  891. <section id="">
  892. <p class="pairing-subheading">Ways to tackle</p>
  893. <p>Again, don't pair 8 hours a day, agree on core coding hours with your team and
  894. keep it to a maximum of 6 hours per day. Maybe you also want to
  895. allocate a few hours self learning time.</p>
  896. <p>When a pair feels that they don't have the collective knowledge to
  897. approach a problem, split up to read up and share back, then continue
  898. implementation.</p>
  899. </section>
  900. </section>
  901. <section id="RotationsLeadToContextSwitching">
  902. <h3>Rotations lead to context switching</h3>
  903. <p>Knowledge sharing is one of the benefits of pairing, and we have mentioned how
  904. <a href="#PairRotations">rotations</a> can further increase that effect. On the other hand,
  905. too may rotations leat to frequent context switching.</p>
  906. <section id="">
  907. <p class="pairing-subheading">Ways to tackle</p>
  908. <p>Find a balance between frequency of rotations and the possibility for
  909. a new pairing partner to get enough context on the story and
  910. contribute properly. Don't rotate for the rotation's sake, think about
  911. if and why it is important to share a certain context, and give it enough time to be effective.</p>
  912. </section>
  913. </section>
  914. <section id="PairingRequiresVulnerability">
  915. <h3>Pairing requires vulnerability </h3>
  916. <blockquote>
  917. <p>To pair requires vulnerability. It means sharing all that you know
  918. and all that you don't know. This is hard for us. Programmers are
  919. supposed to be smart, really-crazy-smart. Most people look at what we do
  920. and say 'I could never do that.' It makes us feel a bit special, gives
  921. us a sense of pride and pride creates invulnerability.</p>
  922. <p class="quote-attribution">-- <a href="https://diaryofascrummaster.wordpress.com/2013/09/30/the-shame-of-pair-programming/">Tom Howlett</a></p>
  923. </blockquote>
  924. <p>When you pair, it can be hard to show that you don't know something, or feel insecure about a decision. Especially in
  925. an industry where myths like the <a href="https://www.thoughtworks.com/radar/techniques?blipid=201911057">10x engineer</a> regularly make their rounds, and where we have a tendency
  926. to <a href="https://blog.aurynn.com/2015/12/16-contempt-culture">judge each other</a> by what languages we use, or what design decisions we took 5 years ago.</p>
  927. <p>Vulnerability is often connected with weakness and in most modern
  928. cultures the display of strength is the norm. But as the researcher
  929. Brené Brown has laid out in several talks and books, vulnerability
  930. is actually a very important ingredient for innovation and change.</p>
  931. <blockquote>
  932. <p>Vulnerability is the birthplace of Innovation, Creativity and
  933. Change.</p>
  934. <p class="quote-attribution">-- <a href="https://www.youtube.com/watch?v=psN1DORYYV0">Brené Brown</a></p>
  935. </blockquote>
  936. <section id="">
  937. <p class="pairing-subheading">Ways to tackle</p>
  938. <p>Showing vulnerability requires courage and creating an environment
  939. where people feel safer to show that their vulnerable.
  940. Again, this is all about building teams where people trust each other
  941. (regular 1:1s, Feedback, culture where people can ask questions, etc)</p>
  942. <p>Being vulnerable is easier and less risky for people on the team who
  943. have more authority, either naturally (e.g. because they are well-respected
  944. already), or institutionally (e.g. because they have a title like "Tech
  945. Lead"). So it's important that those people start and role model this,
  946. making it the norm and therefore safer for others to be vulnerable as
  947. well.</p>
  948. </section>
  949. </section>
  950. <section id="ConvincingManagersAndCo-workers">
  951. <h3>Convincing managers and co-workers</h3>
  952. <p>Advocates of pair programming often struggle to convince their managers or their co-workers
  953. to make pairing part of a team's daily routine.</p>
  954. <section id="">
  955. <p class="pairing-subheading">Ways to tackle</p>
  956. <p>There is not a simple recipe to persuade others of the efficacy of pair programming. However,
  957. a key element should always be to take time to talk about it first, and make sure that everybody
  958. has the same understanding (e.g. by reading this article :-) ). Then find a way to try it out,
  959. either by starting with one pair who share their experience with the others, or by proposing a
  960. team experiment, like "let's pair by default for the next 2 sprints". Make sure to build in
  961. opportunities for feedback and retrospection to share what is going well and what you are struggling with.</p>
  962. <p>
  963. Ultimately, you can't force a practice on people, and it does not work for everybody. You might end up pairing
  964. with only a part of the team - at least in the beginning. From our experience the best way to convince people
  965. is by having a regular exposure to the practice, experiencing the benefits and fun their team members have while pairing.
  966. </p>
  967. <p>
  968. A question that comes up most frequently in this situation is the economics of the practice: Does pairing
  969. just cost double the money, and is it ultimately worth extra cost because of the increased quality and team benefits? There
  970. are a few studies on the topic, most notably <a href="https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF">this one</a>, that are
  971. cited to provide evidence that pairing is worth it. We are wary though of attempts to "scientifically prove"
  972. pairing effectiveness. Software development is a process full of change and uncertainty, with a lot of outcome
  973. beyond lines of code that is hard to compare and measure, like analysis, testing, or
  974. <a href="https://martinfowler.com/articles/is-quality-worth-cost.html">quality</a>. Staunch opponents
  975. of pairing will always find ways to poke holes into the reproducibility of any "scientific" experiments set up
  976. to prove development productivity. In the end, you need to show that it works for YOU - and the only way to do
  977. that is to try it in your environment.
  978. </p>
  979. </section>
  980. </section>
  981. </section>
  982. <section id="ToPairOrNotToPair">
  983. <h2>To pair or not to pair</h2>
  984. <p>Our experience clearly shows that pair programming is a crucial
  985. practice to create high quality, maintainable software in a sustainable
  986. way (see <a href="#Benefits">"Benefits"</a>). However, we also
  987. don't believe it is helpful to
  988. approach it dogmatically and <i>always</i> pair. How exactly pair programming
  989. can be effective for you, how much of it, and for which tasks, can vary. We've
  990. found it useful to set pair programming as the "sensible default" on teams, and
  991. then discuss whenever we want to make an exception.</p>
  992. <p>Let's look at a few examples where it's helpful to balance how and when
  993. you pair.</p>
  994. <section id="BoringTasks">
  995. <h3>Boring Tasks</h3>
  996. <p>Some coding tasks are "boring", e.g. because they are about using
  997. some well defined boilerplate approach - so maybe you don't need to
  998. pair? The whole team already knows this type of approach, or it's very
  999. easy to grasp, so knowledge sharing is not that important? And live code
  1000. review is less useful because the well-established pattern at hand has
  1001. been used successfully in the past? So yes, maybe you don't need to
  1002. pair.</p>
  1003. <p>However, always consider that <a href="https://www.martinfowler.com/bliki/PairProgrammingMisconceptions.html">
  1004. rote tasks might be a smell for bad design</a>: Pairing can help you
  1005. find the right abstraction for that boring code. It's also more probable
  1006. to miss things or make cursory errors when your brain goes into "this
  1007. is easy" autopilot.</p>
  1008. </section>
  1009. <section id="couldIReallyDoThisByMyself">
  1010. <h3>"Could I Really Do This By Myself?"</h3>
  1011. <p>Pairing has a lot of benefits for programmers who are just starting
  1012. out, because it is an opportunity to learn relatively quickly from a
  1013. more experienced member of the team. However, junior programmers can
  1014. also experience a loss of confidence in their own abilities when
  1015. pairing. "Could I really do this without somebody looking over my
  1016. shoulder?". They also miss out on learning how to figure things out by
  1017. themselves. We all go through moments of frustration and unobserved
  1018. experimentation with debugging and error analysis that ultimately make
  1019. us better programmers. Running into a problem ourselves is often a
  1020. more effective learning experience than somebody telling us that we
  1021. are going to walk into it.</p>
  1022. <p>There are a few ways to counteract this. One is to let junior
  1023. programmers work by themselves from time to time, with a mentor who
  1024. regularly checks in and does some code review. Another way is letting
  1025. the more junior programmers on the team pair with each other. They can
  1026. go through finding solutions together, and still dig themselves out of
  1027. rabbit holes faster than if they were coding by themselves. Finally,
  1028. if you are the more experienced coder in a pair, make sure to be in
  1029. the navigator's seat most of the time. Give the driver space to figure
  1030. things out - it's sometimes just a matter of waiting a little bit
  1031. until you hit that next wall together, instead of pointing it out
  1032. beforehand.</p>
  1033. </section>
  1034. <section id="CodeReviewVs.Pairing">
  1035. <h3>Code Review vs. Pairing</h3>
  1036. <blockquote>
  1037. <p>The advantage of pair programming is its gripping immediacy: it is
  1038. impossible to ignore the reviewer when he or she is sitting right next
  1039. to you.</p>
  1040. <p class="quote-attribution">-- <a href="https://blog.codinghorror.com/pair-programming-vs-code-reviews/">Jeff Atwood</a></p>
  1041. </blockquote>
  1042. <p>Many people see the existence of a code review process as reason
  1043. enough not to need pair programming. We disagree that code reviews are a
  1044. good enough alternative to pairing.</p>
  1045. <p>Firstly, there are usually a few dynamics at play that can lead to
  1046. sloppy or superficial code reviews. For example, when coder and reviewer
  1047. rely too much on each other without making that explicit: The coder
  1048. might defer a few little decisions and improvements, thinking that
  1049. problems will be caught in the review. While the reviewer then relies on
  1050. the diligence of the coder, trusting their work and not looking too
  1051. closely at the code. Another dynamic at play is that of the <a href="https://www.behavioraleconomics.com/resources/mini-encyclopedia-of-be/sunk-cost-fallacy/">sunk cost fallacy</a>: We are usually
  1052. reluctant to cause rework for something that the team already invested
  1053. in.</p>
  1054. <p>Secondly, a code review process can disrupt the team's flow. Picking
  1055. up a review task requires a context switch for somebody. So the more
  1056. often code reviews occur, the more disruptive they will be for
  1057. reviewers. And they should occur frequently, to ensure continuous
  1058. integration of small changes. So a reviewer can become a bottleneck to
  1059. integrate and deploy, which adds time pressure - again, something that
  1060. leads to potentially less effective reviews.</p>
  1061. <p>With <a href="https://martinfowler.com/articles/continuousIntegration.html">Continuous Integration</a>
  1062. (and Delivery), we want to reduce risk by delivering small chunks of
  1063. changes frequently. In its original definition, this means practicing
  1064. <a href="https://paulhammant.com/2013/04/05/what-is-trunk-based-development/">trunk-based development</a>. With
  1065. trunk-based development, delayed code reviews are even less effective,
  1066. because the code changes go into the master branch immediately anyway.
  1067. So pair programming and continuous integration are two practices that go
  1068. hand in hand.</p>
  1069. <p>An approach we've seen teams use effectively is to pair by default,
  1070. but use pull requests and code reviews for the exceptional cases when
  1071. somebody has to change production code without pairing. In these setups,
  1072. you should carefully monitor as a team that your pull requests don't
  1073. live for too long, to make sure you still practice continuous
  1074. integration.</p>
  1075. </section>
  1076. </section>
  1077. <section id="ButReallyWhyBother">
  1078. <h2>But really, why bother?</h2>
  1079. <p>We talked a lot about the benefits of pair programming, but even more
  1080. about its challenges. Pairing requires a lot of different skills to get
  1081. it right, and might even influence other processes in the team. So why
  1082. bother? Is it really worth the hassle?</p>
  1083. <p>For a team to be comfortable with and successful at pair programming,
  1084. they will have to work on all the skills helpful to overcome its
  1085. challenges: Concentration and focus, task organisation, time management,
  1086. communication, giving and receiving feedback, empathy, vulnerability - and these
  1087. are actually all skills that help
  1088. immensely to become a well-functioning, collaborative and effective
  1089. team. Pairing gives everybody on the team a chance to work on these
  1090. skills together.</p>
  1091. <p>Another factor that is widely talked about today as a success factor
  1092. for effective teams is diversity. Diversity of perspectives, genders,
  1093. backgrounds and skills has proven to improve a team's performance - but
  1094. it often increases friction first. It can even increase some of the
  1095. challenges with pair programming we talked about. For example, one of
  1096. the key ingredients we suggested is showing vulnerability, which is
  1097. especially hard for team members of underrepresented groups.</p>
  1098. <p>Consider this headline from Harvard Business Review: <a href="https://hbr.org/2016/09/diverse-teams-feel-less-comfortable-and-thats-why-they-perform-better">"Diverse Teams Feel Less Comfortable - and That's
  1099. Why They Perform Better"</a>. The authors are making the point that
  1100. "Homogeneous teams feel easier - but easy is bad for performance. (...)
  1101. this idea goes against many people's intuitions". To explain, they point
  1102. out a cognitive bias called the fluency heuristic: "We prefer information
  1103. that is more easily processed, and judge it to be more true, or more
  1104. beautiful."</p>
  1105. <p>This bias makes us strive for simplicity, which serves us very well
  1106. in a lot of situations in software development. But we don't think it
  1107. serves us well in the case of pair programming. Pairing feels hard – but
  1108. that doesn't necessarily mean it's not good for a team. And most
  1109. importantly, it does not have to stay hard. In <a href="https://www.youtube.com/watch?v=S92vVAEofes">
  1110. this talk</a>, Pia Nilsson describes measures her team at Spotify took
  1111. to get over the uncomfortable friction initially caused by introducing
  1112. practices like pair programming. Among other things, she mentions feedback
  1113. culture, non-violent communication, <a href="https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it">
  1114. psychological safety</a>, humility, and having a sense of purpose.</p>
  1115. <p>Pair programming, extreme programming, and agile software development
  1116. as a whole are all about embracing change. Agile software practitioners
  1117. acknowledge that change is inevitable, so they want to be prepared for
  1118. it.</p>
  1119. <p>We suggest that another thing we should embrace and prepare for is
  1120. friction, because it's also inevitable on the way to becoming a highly
  1121. effective, diverse team. By embracing friction we do NOT mean to say,
  1122. "let's just have lots of conflicts and we'll get better". What we mean
  1123. is that teams should equip themselves with the tools necessary to deal
  1124. with friction, and have them in their toolbox by default, not just when
  1125. the team is already having problems. Practice feedback, improve team
  1126. communication, take measures to create a psychologically safe
  1127. environment.</p>
  1128. <p>We believe that pair programming is often avoided because it can
  1129. create friction, but we would ask you to give it a chance. If you
  1130. consciously treat it as an improvable skill, and work on getting better
  1131. at it, you will end up with a more resilient team.</p>
  1132. </section>
  1133. </main>
  1134. </article>
  1135. <hr>
  1136. <footer>
  1137. <p>
  1138. <a href="/david/" title="Aller à l’accueil">🏠</a> •
  1139. <a href="/david/log/" title="Accès au flux RSS">🤖</a> •
  1140. <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
  1141. <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
  1142. <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
  1143. </p>
  1144. <template id="theme-selector">
  1145. <form>
  1146. <fieldset>
  1147. <legend>Thème</legend>
  1148. <label>
  1149. <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
  1150. </label>
  1151. <label>
  1152. <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
  1153. </label>
  1154. <label>
  1155. <input type="radio" value="light" name="chosen-color-scheme"> Clair
  1156. </label>
  1157. </fieldset>
  1158. </form>
  1159. </template>
  1160. </footer>
  1161. <script type="text/javascript">
  1162. function loadThemeForm(templateName) {
  1163. const themeSelectorTemplate = document.querySelector(templateName)
  1164. const form = themeSelectorTemplate.content.firstElementChild
  1165. themeSelectorTemplate.replaceWith(form)
  1166. form.addEventListener('change', (e) => {
  1167. const chosenColorScheme = e.target.value
  1168. localStorage.setItem('theme', chosenColorScheme)
  1169. toggleTheme(chosenColorScheme)
  1170. })
  1171. const selectedTheme = localStorage.getItem('theme')
  1172. if (selectedTheme && selectedTheme !== 'undefined') {
  1173. form.querySelector(`[value="${selectedTheme}"]`).checked = true
  1174. }
  1175. }
  1176. const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
  1177. window.addEventListener('load', () => {
  1178. let hasDarkRules = false
  1179. for (const styleSheet of Array.from(document.styleSheets)) {
  1180. let mediaRules = []
  1181. for (const cssRule of styleSheet.cssRules) {
  1182. if (cssRule.type !== CSSRule.MEDIA_RULE) {
  1183. continue
  1184. }
  1185. // WARNING: Safari does not have/supports `conditionText`.
  1186. if (cssRule.conditionText) {
  1187. if (cssRule.conditionText !== prefersColorSchemeDark) {
  1188. continue
  1189. }
  1190. } else {
  1191. if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
  1192. continue
  1193. }
  1194. }
  1195. mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
  1196. }
  1197. // WARNING: do not try to insert a Rule to a styleSheet you are
  1198. // currently iterating on, otherwise the browser will be stuck
  1199. // in a infinite loop…
  1200. for (const mediaRule of mediaRules) {
  1201. styleSheet.insertRule(mediaRule.cssText)
  1202. hasDarkRules = true
  1203. }
  1204. }
  1205. if (hasDarkRules) {
  1206. loadThemeForm('#theme-selector')
  1207. }
  1208. })
  1209. </script>
  1210. </body>
  1211. </html>