Practical Remote Pair Programming

Best practices, tips, and techniques for collaborating productively with distributed development teams

Adrian Bolboacă

• Publisher: Packt Publishing
• Year: 2021
• ISBN:
  9781800565531
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

A practical guide for developers, development teams, and managers to successfully implement remote pair programming techniques and styles that better fit their organization's environment

Key Features

• Implement remote pair programming best practices in your organization to increase productivity in software development teams
• Overcome the challenges in communication while working with distributed teams across the globe
• Explore remote pair programming tools and learn smart ways to use them efficiently

Book Description

Remote pair programming takes pair programming practices to the next level by allowing you and your team members to work effectively in distributed teams. This helps ensure that you continuously improve code quality, share equal ownership of the code, facilitate knowledge sharing, and reduce bugs in your code. If you want to adopt remote pair programming within your development team, this book is for you.

Practical Remote Pair Programming takes you through various techniques and best practices for working with the wide variety of tools available for remote pair programming. You'll understand the significance of pair programming and how it can help improve communication within your team. As you advance, you'll get to grips with different remote pair programming strategies and find out how to choose the most suitable style for your team and organization. The book will take you through the process of setting up video and audio tools, screen sharing tools, and the integrated development environment (IDE) for your remote pair programming setup. You'll also be able to enhance your remote pair programming experience with source control and remote access tools.

By the end of this book, you'll have the confidence to drive the change of embracing remote pair programming in your organization and guide your peers to improve productivity while working remotely.

What you will learn

• Develop a structured organizational approach to implementing pair programming and using it effectively
• Understand how pair programming fosters better communication inside and outside the team
• Organize remote pair programming and choose the right style for your organization
• Set up screen sharing, IDE, source control rules, audio, and video for your remote pair programming setup
• Use various pair programming techniques and styles in the context of a remote environment
• Enhance your remote pair programming experience with source control and remote access tools

Who this book is for

This book is for any developer who wants to understand the different practical aspects involved in remote pair programming and adopt them in their existing development teams. If you're a team leader or technical manager, this book will serve as a manual for implementing remote pair programming covering the best resources for you to manage communication and collaboration using pair programming with your team members working remotely in distributed teams.

Section 1: Introduction to Pair Programming

This section is a first touch on the topic of pair programming, where we get to understand the topic, when to apply pair programming, and how to start.

This section has the following chapters:

• Chapter 1, Pair Programming and Its Necessity
• Chapter 2, How Can Pair Programming Help?
• Chapter 3, Usual Pair Programming Techniques and Styles

Chapter 1: Pair Programming and Its Necessity

Pair programming can be easy to use when you are focusing on building software that is of high quality. You, as a programmer, can pair with other programmers to find quicker solutions to your problems and get better results. Furthermore, you can pair with other colleagues: testers, analysts, (dev)ops, security, and so on.

Pair programming in itself is simple: you have a driver who writes the code and a navigator who oversees the code. The two are roles that can change slower or faster, depending on your context. We will learn about them in more detail as this book progresses.

You can use pair programming in many moments. Typically, we pair program naturally when we are stuck and ask for a colleague's help. Also, we can schedule pairing sessions as a regular activity. Some like to pair daily, or just a few times per week. It's a matter of context and where it helps you get better results.

Usually, you pair program in the office, at your desk, or at your colleague's desk. You can take your laptop(s) and pair in a meeting room on a big screen, or on a terrace when the weather's nice. Or, you can remote pair program by using specific tools to pair with people wherever in the world, as long as they have good internet.

Continuous learning, improved quality, fewer defects, managing complex problems, and solving specific problems faster are just a few reasons to use pair programming. Because programmers deal with a mass of knowledge, wrapping your head around all the essential details with another colleague helps your endeavor with speed and quality.

In this chapter, we will cover the following topics:

• The history of pair programming
• Elucidating problems in pairs
• Sharpening knowledge with collaboration
• Gaining wisdom
• Managing complexities in complex domains
• Comfort for the future you
• Programming with your CEO
• How does pair programming work?

The history of pair programming

Pair programming has been around for a long time in the history of software development, even from the early days, when programming meant plugging in some wires into a control dashboard or inserting punch cards into a reader in order to compile your program.

It's just that people who used to program back in the day didn't call it pair programming; they called it simple, plain programming. You needed to do things in pairs because of the wires or the cards that were cumbersome to use.

Then came the era of industrial programming where, little by little, pushed by the need for automatization and computers being more affordable, programmers were working more and more alone. It was an age of simpler programs, but it took a long time to write, compile, check, fix, improve, write, compile, and so on.

After a while, computers started becoming more powerful and even more affordable. So, companies started automating more complex parts of their business flows. We are talking about financial systems, travel, trade, and so on. You had a complex domain already, but programmers were working alone, as in any other factory. They had a boss, like in any other factory, and a manager, like in any other factory.

The only problem with comparing factory workers with programmers is that programmers need to solve problems that are from non-routine work, while factory workers had a clear routine that might have been subject to change every once in a while. That is the moment when the concept of the knowledge worker appeared in the management literature:

"Every knowledge worker in a modern organization is an "executive" if, by virtue of his position or knowledge, he is responsible for a contribution that materially affects the capacity of the organization to perform and to obtain results."

- Peter Drucker in The Effective Executive (1966)

Pair programming then reappeared in some areas, and younger programmers read about the older ways of programming. They started using it with great success, and it felt very natural to have two people coding for a task. Plain pair programming is a simple system of managing complexity and gaining better results.

Elucidating problems in pairs

The best way of explaining why pair programming works is that two people can understand how to write some code better than just one programmer. It is true that when we code trivial parts of the system, pair programming is unnecessary – even counterproductive. So, it's important to choose when to pair program and when to solo program.

Here are a few situations where pair programming works great, and where the two heads are better than one rule applies:

• A junior programmer learning from a senior programmer.
• A new programmer in a team learns from an existing programmer in the team.
• Fresh tasks are assigned to the team, and two people can tackle the problem better and faster.
• A programmer learns new practice (that is, test-driven development, unit testing, and so on).

As a rule of thumb, it is a good idea to use pair programming when we have a task with higher complexity, either the technical or the business side. It's good to acknowledge that programmers are more likely to make mistakes in complex or unknown areas of code.

There are situations where we'll have simple, trivial tasks that don't necessarily need pairing, or even more, where pairing would be just a waste of time for at least one of the two. Often, it's a good idea to have this discussion with the whole team. After all, it should be the decision for the whole team on how they use their common time, what the learning or improvement focus is in the next period, and where they can't afford pairing because they need to deliver faster.

Should I pair? Before you start a new task, ask yourself the following questions:

• How would I benefit from using pair programming?
• How would the team/product benefit from using pair programming?
• Would we learn anything useful for the team by pairing?
• Would pair programming delay a delivery?
• Would pairing on this task be boring or superfluous?

These questions could help you and your team decide if it's worth investing in pair programming for that specific task. Yes, it is an investment, and you should treat every decision with objectivity and respect for the rest of the team. After all, two heads are better than one in some situations, though in other situations, where even one head wouldn't be used too much, using pair programming would just be a waste of time and energy.

Managing complexity

Following the idea that two heads are better than one, we can use pair programming to manage better complexity.

Let's face it: programmers almost never do the exact same task. It might be that the domain is similar, or identical, but there are so many moving parts in the whole ecosystem, such as programming language, frameworks, external or internal use libraries, programming patterns, architecture patterns, business domain variations, performance, security, scalability, and so on. A programmer needs to think about all these and more when writing code. That is why we can make a strong case when we say complexity is inherent in most programming tasks.

Having two people who look at all the aspects of the code is clearly beneficial. There is a driver who writes the code and a navigator who oversees the code, thinks about possible next steps, thinks about possible caveats, and improves the code while it is being written.

Humans only have one brain, and we can only focus our full attention on one thing. We can pivot our focus from one aspect to another, but that is tiring and during the switch, we might lose some details. That is why the driver focuses on writing the code while looking at low-level details such as code syntax, code logic, framework/library usage, or code formatting. And, at the same time, the navigator focuses on high-level details such as design aspects, architecture concerns, performance, security, and so on.

After all, what pair programming does is split the overall complexity into smaller, less complex parts that are easier to manage. These smaller parts are managed by two people, who use the clear responsibilities that are attributed to the driver and the navigator.

A good guideline is necessary for clarifying the driver and navigator roles before starting the pair programming ...

Table of contents

• Practical Remote Pair Programming
• Contributors
• About the author
• About the reviewer
• Preface
• Section 1: Introduction to Pair Programming
• Chapter 1: Pair Programming and Its Necessity
• Chapter 2: How Can Pair Programming Help?
• Chapter 3: Exploring Pair Programming Techniques and Styles
• Section 2: Remote Pair Programming
• Chapter 4: Using Pair Programming in a Distributed System
• Chapter 5: Remote Pair Programming Setup
• Chapter 6: Remote Pair Programming-Specific Techniques and Styles
• Section 3: Tools to Enhance Remote Pair Programming
• Chapter 7: Video and Audio
• Chapter 8: Source Control Rules
• Chapter 9: Remote Access
• Other Books You May Enjoy