How to find the right context for pair programming

At Sensidev, we highly value practices that enable us to provide the best quality, and pair programming is one of them. Not only that this approach encourages collaborative teamwork, but it can also lead to high-quality software.

Read more: All About Pair Programming

We have a flat management structure, where we focus on code simplicity and clarity. Frequent ad-hoc meetings with fellow #sensidevs or with customers often help us clarify requirements and establish a clear flow for our work.

To reinforce this productive workflow, we have also adopted Pair Programming, a known practice from Extreme Programming that suits our style. Let’s explore how, when, and why it is an important method for devs:

When is the right moment for pair programming

Personally, I think pair programming is welcome most of the time. It doesn’t matter if you are in school working on a simple project with your colleagues, a startup SaaS project, or even within a corporation.

But for this to work well, you need two passionate software engineers (doesn’t matter the level of expertise), who are up for the challenge and are committed to working together to implement a new user story. Ideally, the two developers must be familiar and work with the same tech stack (eg: two backend developers or two frontend developers). Of course, a full-stack developer can pair with either one.

When I don’t recommend pair programming is when you are tired or feel unproductive because this technique is quite intense for both the Driver and Observer.

The Setup

We mostly work remotely, therefore our pair programming takes place the same — online. Essentially, a decent internet connection is enough to get it started. Most of the time, we are using a simple online conference platform to share our screen, but you can get much fancier than that if you want to, by using VSC or JetBrains features — you can find them all in our previous blog post.

For me, the classic pair programming method, which takes place at the same desk and you have to share the same keyboard, feels quite intrusive and I can't focus that well. The monitor angle and physical discomfort don’t bring out the best work practices in me. However, I can 100% focus on a screen share, when I do a remote video call from my comfy setup, and I totally recommend doing this remotely.

The Driver is responsible for writing the actual code, but also narrating the mental process.
Example: “Now let’s write this method to filter the latest entities from the database”. This way, the Observer is engaged and contributes back quickly when the Driver is having difficulties or simply asks for help.

Usually, we rotate each hour or two, with a small break in between. Being the Observer is not lighter than being the Driver, because you have to be very careful maintaining the bigger picture, answering any question the Driver might have (like: how should we name this method?), and be engaged in reviewing the code as it is written.

Sometimes we apply TDD (Test Driven Development) techniques, sometimes we don’t — depending on many factors. For example, we apply TDD when we develop our service layer, holding pure business logic and it makes it clear what we expect and in which format. Then it makes sense to write a failing test first, as an entry point for our service class in development.

💆‍♂️ Deep work is key while practising PP. Don’t let yourself be distracted by random notifications. Stop or have a break when at least one of you is tired or can’t focus anymore. Even if you did start together, you can still continue on separate paths. However, this is not ideal, since a full code review is still needed in the end in order to move on, whereas if you continue PP all the way to the end, extra code reviews would not be necessary.

The real benefits of this approach

→ It is a great way to better know your teammates, their habits, what tools they use, how they are thinking about a certain problem — you can even better connect with them.
→ Both devs involved have something to learn from each other, even if it is a junior-senior level session.
→ It is enjoyable to work this way, you feel part of the team.
→ The resulting code has fewer defects, and we consider it is already reviewed, no need for a pull request.
🎁 Bonus: in the best scenarios, you get a good laugh with your colleagues.

Bottom Line

We highly recommend pair programming if you want to maximize your team’s efforts and encourage a collaborative environment. Our work is highly improved by this practice.

Want to find out more about our work practices? Our customers love to work with Sensidev, because we embrace early change requests, we deliver working software every day and we build with care:

• By always clarifying requirements before implementing.
• By reviewing our code, making sure it is extensible and clean.
• By writing unit tests to avoid future defects from code refactoring.
• By adopting evolutionary design principles.
• By presenting a demo after each sprint to all stakeholders.

If you want to be a part of this, keep an eye on our careers page, and don’t hesitate to contact us!