{"id":14483,"date":"2023-08-30T13:53:24","date_gmt":"2023-08-30T10:53:24","guid":{"rendered":"https:\/\/railsware.com\/blog\/?p=14483"},"modified":"2024-12-12T13:10:45","modified_gmt":"2024-12-12T10:10:45","slug":"what-is-pair-programming","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/what-is-pair-programming\/","title":{"rendered":"What is Pair Programming and How to Practice it in a Remote Team"},"content":{"rendered":"\n
Pair programming is one of the most controversial and widely debated agile development practices. Some engineering teams swear by it, while others remain skeptical of its benefits. But is pair programming worth the time and effort, or is it just another overhyped engineering trend? In this post, we dive into the pros and cons of pairing sessions, explain the different roles and pairing types, and share tips from our own experience with remote pair programming.<\/div>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n

What is pair programming?<\/h2>\n\n\n\n

 Pair programming is an activity where two developers work simultaneously on the same coding task. It\u2019s an agile software development<\/a> concept that originates from Extreme programming<\/a> methodology, first popularized in the 1990s.<\/p>\n\n\n\n

Practically speaking, pair programming is based on the four-eyes principle or the idea that \u2018two heads are better than one.\u2019 When developers write code in pairs rather than alone, they can collaborate on tasks, share knowledge, discuss ideas in real time, and problem-solve on the go. The goal is to create better quality code, unify the development team, and create a more robust, innovative product overall.<\/p>\n\n\n\n

How does it work?<\/h3>\n\n\n\n

Traditionally, two developers shared a single computer and took turns writing or reviewing code. However, an estimated 66%<\/a> of global software engineers now work remotely, meaning modern-day pair programming sessions often occur online.<\/p>\n\n\n\n

In a remote pair programming session, one developer shares their screen (displaying the IDE or code editor) and writes the actual code. Meanwhile, the other developer provides guidance on what to write or reviews what is being written. That\u2019s the basic dynamic. However, variables like the style and types of pairings often affect the structure, flow, length, and purpose of a pair programming session.<\/p>\n\n\n\n

At Railsware, we\u2019ve been practicing pair programming since our inception. Over the past 16 years, we\u2019ve seen the positive effects that pair work has had on individuals, the team, and the company overall. It\u2019s what inspired our software agency to expand this practice to other software development activities and internal functions.<\/p>\n\n\n\n

\n
\u201c<\/div>\n
\n

A job of an engineer isn’t just to write code. You also spend time planning your work, discussing solutions, debugging, testing, evaluating requirements, and many other things on which you spend your workday.<\/p> \n

In my experience, we practiced pairing on almost all of these activities, and it worked well.<\/p>\n

 <\/p>\n<\/div>\n

\"Artur\n

 <\/p>\n

Artur Termenji<\/h4>\n

Full Stack Engineer<\/p>\n

 <\/p>\n<\/div>\n<\/div>\n\n\n\n

P.S. We share our experience with building sustainable remote collaboration workflows<\/a> in a separate post.<\/p>\n\n\n\n

Code review vs. pair programming<\/h3>\n\n\n\n

Code (or PR reviews<\/a>) and pair programming are completely different practices (although equally important to the Lean software development process<\/a>, we\u2019d argue).<\/p>\n\n\n\n

Usually, a PR review is carried out asynchronously. An engineer checks the pull request submitted by one of his teammates, and either approves it, or informs their teammate of any issues that require attention.<\/p>\n\n\n\n

On the other hand, pair programming takes place in real time and isn\u2019t exclusively focused on code analysis. Engineers don\u2019t systematically review each line of code that is written during a session, although they do pay close attention to the quality of the work being produced.<\/p>\n\n\n\n

Sometimes, depending on the seniority of engineers, pair-programmed code is approved and merged on the spot. But it\u2019s also common for pull requests that were shaped during a pairing session to undergo an independent code review.<\/p>\n\n\n\n

Types of pairing in pair programming<\/h2>\n\n\n\n

There are three main types of pairings, made up of the following roles:<\/p>\n\n\n\n