Pairing is daring

WHY PAIR PROGRAMMING SHOULD BE IN EVERY TEAM’S TOOLBOX

Pair programming is old news for most developers. It’s quite possible that you “paired” with a colleague before and might have had some good and some bad experiences. In this blog post, you will get a quick overview of pair programming. You will learn that there are lots of benefits and potential downsides. Additionally, there are some hints on the process and pitfalls to keep in mind. Finally, you will find a quick overview of remote collaboration tools.

BENEFITS OF PAIR PROGRAMMING

According to a study conducted by a Microsoft Research team [1], participating developers reported “fewer bugs”, the “spread of code understanding”, and “higher quality of code” as the main benefits of pair programming.

Fewer Bugs

In many work areas, the four-eyes principle allows teams to spot errors early on. Developers usually conduct code reviews before code goes out to production. Think of pair programming as giving a programmer a second pair of eyes. They might spot bugs right away, leading to reduced friction down the road. The earlier you spot a bug, the easier it is to fix.

@Saad Bin Akhlaq: After a pairing session, I have more confidence in pushing the code since 2 engineers have already gone over it.

Spread of Code Understanding

According to the Agile Alliance, a team that applies pair programming will gain “better diffusion of knowledge among the team, in particular when a developer unfamiliar with a component is pairing with one who knows it much better.” You will notice a “better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members.” Furthermore, the Microsoft study highlights that “there is never only one person in the team who knows all the code”.

In the paper “The Costs and Benefits of Pair Programming” [2] by Alistair Cockburn and Laurie Williams, they claim that “if [a] pair can work together, then they learn ways to communicate more easily and they communicate more often. This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”

@Jobrann Mous: I especially enjoy a pairing session when I am exposed to different topics, codebases, and coding practices.

Higher Quality Code

The authors of the Microsoft study state that pair programming helps to improve code quality “through more extensive review and collaboration.” Also, “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys”, says the Agile Alliance.

In addition to that, a quantitative study at the University of Utah [3] showed that pairs not only completed their programs with superior quality, but they consistently implemented the same functionality as the individuals in fewer lines of code.

Critique of pair programming

In the same study from Microsoft, developers listed cost efficiency, scheduling, and personality clash as their biggest problems when applying pair programming.

Cost efficiency

Management most likely is in doubt about the efficiency of pair programming. In the Microsoft study “the number one problem reported with pair programming is cost. Two people are being paid to do the work of one.” On paper, you halve the allocatable time of two developers. But there are studies suggesting that pair programming actually increases time spent by only 15% (and not 100%), while at the same time reducing the error rate by 15%. [2] Occasional pairing programming will balance out the cost with the benefits.

Scheduling

Yet another meeting? Calendars are already full and scheduling meetings is a pain? Pair programming will not improve the situation. If scheduling a spontaneous pairing session is hard, your team should review the number of meetings in general.

What worked well for the cross-functional engineering teams of Bertha and Mercedes Me Service apps, is a fixed pairing slot every two weeks. The engineers begin the 2 hours slot with a short alignment, check who is available, and what topics they can pair on. Then the pairs (or sometimes groups of more than two) start their sessions.

During sprint planning for Bertha, we schedule pairing sessions to tackle tickets with high estimations together.

The backend team of Reach Me is doing it differently. Instead of scheduling anything, they start their day with a Teams-call which they keep running in the background for most of the day. It simulates a being-together-in-the-office feeling and allows for spontaneous conversations, some of which lead to pair programming sessions.

Personality clash

Pair programming is not the best work mode for every problem. While some of us are happy to collaborate on a task and align with a colleague, others need alone time. They want to play around with different possible solutions, sketch something, etc.

Most programmers tend to shy away from collaborative tasks. They want to be on their own while coding. Practice (and constant nudging) is your only chance to convince introverted people to pick up pairing more often.

There are also big differences in the way people articulate themselves. Pairing a person who thinks longer before answering with a fast speaker might end up in a one-sided conversation. It’s important to give everyone enough space. You don’t need to rush anything.

It is an acquired taste

You sometimes hear “I need to get this done, I don’t have time for a pairing session”. Or “it will take me half the time explaining the issue to my colleague before being productive”. Please reconsider. True, pair programming comes with a cost. You have to set it up, agree on a work mode, explain the context. It adds cognitive overhead. Practice can mitigate most of that. If you are getting used to pair-programming it becomes a standard way of working within your team. Doing so will feel normal, and you will consider it for more and more assignments. Jumping on a pairing session with someone lacking the context should be the outlier.

HOW TO DO PAIR PROGRAMMING

4 simple tips for pair programming. Just give it a try.

Agree on topic and scope

There should be a common understanding of what the problem is, and a general direction of how to tackle it. Keep reminding each other when you are deviating too far from your goal. It’s easy to get lost. Now you have someone helping you to focus!

Pick your role, switch them

Usually, when sitting next to each other at one desk, there is one keyboard to share. This puts the person on the keyboard in a different position than the person next to them. The person who types – the “driver” – is more concerned about the coding details, types, syntax, formatting. The person off the keyboard – the “navigator” – can think about the bigger picture, e.g. abstraction layers, dependencies, potential refactorings, etc.

That situation changes when you are leveraging remote collaboration tools. All participants can now write to the current codebase, they can be “drivers” and “navigators” at the same time.

Regardless of the setup, you should keep all participants engaged by flipping through the two roles. This allows everyone to contribute to the lower-level and big-picture problems.

Acknowledge different pairing situations

You should always be aware of the circumstances and the setting of each session.

@Svitlana Piddubna: “Not all tasks are equally good for pairing, so I think it works best when someone sees a ticket that could be a good one for pairing and offers to work on it together”

Are you and your pairing partner on the same page about the issue? Can you both focus on the issue at hand? Does the schedule suit both of you?

Plan enough breaks beforehand. This allows accommodating for individual daily routines, habits, speed of thought, etc. Especially during a pandemic, we need to pay special attention to a flexible schedule (eg: no daycare!). Some people need their time thinking through things alone. Take a break from the session when needed. Pair programming doesn’t mean you are bound to each other for the whole session.

Consider also the implicit or explicit power dynamic within a pair. An example: You are the most experienced developer in your team. Your pairing partner is a junior member with knowledge of the context, but lacking coding experience. As a senior, you have the responsibility to motivate, acknowledge, and drive the conversation positively. Don’t be condescending, don’t turn it into a lecturing lesson. You only get the inspiration of your counterpart flowing when it is a mutual experience.

Programming out loud

Reflection is an important step in learning. You are allowing your brain to streamline your thoughts on a topic. More often than not, only when attempting to write down or articulate, do you realize that you haven’t understood a problem. Now imagine you are articulating and reflecting on your current assignment. You gain an improved understanding of the topic and your pairing partner gains insights into your thought process.

The Agile Alliance advised, that “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys.”

PRO TIP: Think of TV chefs and how they orate every detail of their process.

Remote pair programming

The obvious downside of remote pair programming is the fact that you can’t grab the keyboard and switch between navigator and driver. The “navigator” is not looking at the same monitor as the person who “drives”. To overcome these barriers, a variety of tools can help.
The easiest and most intuitive solution is simple screen-sharing. If you need more elaborate features, look at tools like JetBrain’s Code With Me and Microsoft’s Live Share. They come with plenty of features to accommodate for a sophisticated pairing session.

Microsoft Teams

At Mercedes-Benz.io the main tool for remote collaboration is Microsoft Teams. Its screen sharing feature already allows for a great remote pairing environment. You set up a call, share your screen, and go. There is even a function to take over the controls of the shared screen. This can be helpful when a topic is hard to articulate or to switch roles between “driver” and “navigator”.

JetBrains Code With Me

The Code With Me service [4] allows any JetBrains IDE user to share and open up their codebase for collaboration with remote colleagues. It works across almost all their IDEs (Android Studio coming soon). You can give your colleagues instant access to your current project. Up to 10 developers can join one session, and collaborate on one codebase. Especially for a mob-programming session, this is quite a valuable solution. Each participant can choose to either sync with (or follow) the “driver” and see what they are seeing, or work on their code area, all within one session.

Visual Studio Live Share

Visual Studio and Visual Studio Code offer a similar service, Live Share [5]. You can start a collaboration session and share a link to it for others to join. You have fine-grained control over the permissions the session members get.

Conclusion

Pair programming is an important tool in the arsenal of software engineering teams. It’s a great way to share knowledge, reduce friction, and increase communication bandwidth. Most of us are currently working remotely. Introducing collaborative work methodologies like pair programming helps you to cope with that. Remote collaboration tools like screen sharing make it super easy to do. Now that you know more about pair programming, try it out more. You will be surprised about the positive outcome!

Reference

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/esem-begel-2008.pdf
[2] https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
[3] https://web.archive.org/web/20041129085715/http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF
[4] https://www.jetbrains.com/code-with-me/
[5] https://visualstudio.microsoft.com/de/services/live-share/

The top five articles of January from tech practice

We hope you had as good a start to the new year as we did. In the new year, we have news fodder again and therefore prepared small snacks for you to digest. #

UPCOMING CONFERECES

– Not only reading but attending conferences is also a great way to absorb new knowledge. Getting a good overview of upcoming conferences and finding the right ones for you is important. Dev.events created a helpful list from different tech areas. The list can be filtered by country and preferred technology. Pick the right one for you.


FOR ALL DILIGENT DIAGRAM ARTISTS 

– there is an extension for draw.io diagrams for visual studio code. This is worth its weight in gold if you want to manipulate values and diagrams programmatically or collaborate with others.


NOT ONLY VISUAL STUDIO CODE IS EVOLVING 

–  Jetbrains is also working on improving the user experience. That’s why they have a new editor currently in the preview phase called Fleet. The IDE promises lightweight, flexibility, collaboration, language inclusion, and much more. Check out the features in detail or subscribe to the updates once the IDE is available after the preview phase.


THE HISTORY OF THE <div> ELEMENT 

– the article shows the misuse and spans the arc to the semantically correct use of elements. Of course also the resulting advantages in terms of accessibility.


A NEW FUNCTION structuredClone() 

– will soon be supported by most browsers. It creates deep copies of objects. This blog post explains how it works.

BONUS
Are you still using git stash, new branch, and git stash apply then? Optimize your workflow and check out git switch.

ARTICLES BY MB.IONEERS
Hido has written another great article on the topic of remote work. There he illuminates this with a psychological eye and gives you tips to use at home. Check it out.

Andre wrote an article about what has been concerning us for a long time. He offers a solution on how to realize the execution of multiple versions of a stencil design system without conflicts. Check it out.

Enjoy reading and stay curious.

TECH PRACTICE: TOP 5 ARTICLES OF OCTOBER

For us, it is important to share interesting tech articles related to programming and our work environment.

In our October list, you find valuable insights from the areas of frontend development, mobile development, and quality assurance. Get inspired by the news we have gathered for you!

THE TOP FIVE OF OCTOBER:

1. An Interview With Elad Shechter on “The New CSS Reset”
2. This article discusses the benefits of Shift Left Testing in the software development lifecycle and the key considerations on how to maximize the success of a product by using this approach.
3. VS Code introduces a lightweight version of vscode.dev that runs entirely in the browser. Coding can thus also be done via a smartphone. Clicking on the “.” button in any public repository will open the vscode browser version for comfortable multi-editing of the files. What do you think, will you make use of it?
4. Apple introduces Tech Talks 2021, live online sessions for developers offering the opportunity to talk directly with Apple experts for receiving personal advice.
5. In this article, you find exciting and fun things we can do with CSS for common UI challenges.

BONUS

1. Netflix developers are pretty good at writing articles on their own tech blog. Have a look. 
2. This article in particular is recommended for people who want to get to grips with image formats in a very excessive way.

Stay curious.

A big thank you to Claudio, Gabriel, Ruben, and Christian who regularly share interesting news with us.

TECH PRACTICE: TOP 5 ARTICLES OF SEPTEMBER

For us, it is important that we share what we discover interesting in the world. Which articles we read especially in relation to programming and our work environment. Therefore, we actively share articles with you.

The result is a list of the top five articles created from the interactions with the articles shared by you as MB.ioneers.

TOP FIVE OF SEPTEMBER:

1. What if we can just play games and learn something new while playing? Find out here with a very extensive list of web applications with which you can learn through play.

2. An article that deals with the difference between the variable types “any” and “unknown”, explains them with an example and shows the advantages. https://dmitripavlutin.com/typescript-unknown-vs-any/

3. Attention! Be careful when using the dot operator and reflect on whether destructuring the values is possible and makes more sense.

4. What are pitfalls when using NPM or how do you deal with upgrades?

5. It’s this time of the year again that open source maintainers love because of Hacktoberfest! It’s usually a nice time of the year to look to contribute to OSS because everyone is doing, so maintainers are usually very active in approving and interacting with your PRs. Start actively participating in the open-source community and find the first simple steps here!

But please read for yourself and stay curious.

BONUS ARTICLES

by Roman Guivan who has just started a multi-part Pixi.js game tutorial. follow him on his journey.

and Barbara Jöbstl with a Unix command cheat sheet which is perceived by the community as very complete.

A big thank you to all those who actively share articles with their colleagues at MB.io. You guys are great.