Book Image

Practical Remote Pair Programming

By : Adrian Bolboacă
Book Image

Practical Remote Pair Programming

By: Adrian Bolboacă

Overview of this book

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.
Table of Contents (14 chapters)
1
Section 1: Introduction to Pair Programming
5
Section 2: Remote Pair Programming
9
Section 3: Tools to Enhance Remote Pair Programming

Remote strong style

As we discussed in Chapter 3, Usual Pair Programming Techniques and Styles, strong style is a very specific way of pairing that is used a lot in mob programming.

There is the driver, who writes the code and focuses on short-term minor details but cannot decide on anything. The driver only focuses on the low-level implementation details, which can be rectified by the navigator at any point in time. A good practice is for the driver to ask for confirmation from the navigator before starting to implement the navigator's idea. With strong style, you can say that the driver acts as a smart keyboard, who is just implementing the navigator's directions.

Then, there is the navigator, who makes all the decisions and focuses on the long-term strategy. The navigator is usually more experienced and carries out responsibilities from a strategic and structural point of view. The navigator thinks more about software design, the architecture, its impact on other...