Nikolas Knickrehm

3 min read

Why Live Share is Not Ideal for Pair Programming

Software Development

For over one year my current team was using the Live Share plugin for VS Code and more recently also Code With Me for IntelliJ on a daily basis due to our remote setup. While initially I really loved this highly collaborative way of remote pair programming I now see a lot of issues with it.

Why Live Share is Not Ideal for Pair Programming

Working together in such a shared session often reinforces the personality traits of the developers involved and from my experience, most sessions are dominated by more extroverted developers. Colleagues working in other teams could confirm my observations and described that more introverted, insecure and junior developers tend to silently watch a lot while more extroverted, confident, and senior developers are more active participants.

This is bad!

Most principles of pair programming have one thing in common: Both pairs should in the end be equally involved in the experience and both produce code.

In a non-remote setup, you often experience a Driver-Navigator pair programming style where one person (the driver) owns the keyboard and "drives the code" while the other person (the navigator) keeps the broader context in mind and assists their pair. You would switch roles multiple times during a session.

Quick note: There are different approaches on when to switch roles. Most commonly a timer is used. When doing Test-Driven Development (TDD) you can also try something like this: One person writes a test; you switch roles; the other person implements the logic to fulfill the test and writes the next test; you switch roles again; repeat.

When working with highly collaborative tools such as Live Share the pairing is usually way more chaotic, because both pairs can (and in most cases will) write code at the same time. Often the pairs are working within the same file just a few lines apart, sometimes they are working in different files at the same time. In any case, the pairs will focus on different parts of the code while trying to be aware of what the other person is doing.

In my opinion, this is far more exhausting because you lose all of the advantages of a usual Driver-Navigator pairing session and you could even say that it is a less collaborative approach.

Meet Mob

Mob is an Open Source tool for pair programming that allows you to work locally on the code and performing quick hand-overs via Git through a temporary work-in-progress (WIP) branch using just one command on both sides.

The idea is that you will again pair in a more traditional Driver-Navigator style and focus on your role at any given time. Only one person can work on the code and is sharing their screen while doing so. After some time (mob even allows you to set a timer when starting a session) you will perform a hand-over and the next person is taking control becoming the new driver. As suggested by the name, Mob can be used for mob programming as well where an arbitrary number of developers can be involved.

GitHub - remotemobprogramming/mob: Tool for smooth git handover.
Tool for smooth git handover. Contribute to remotemobprogramming/mob development by creating an account on GitHub.

A mob session ends with the last driver issuing another command (you really just need to remember three commands when working with Mob). This will remove the WIP branch and stage all the changes so that you can complete the session with one or more commits on your real branch.

When using Mob in a Git repository that is connected to a CI pipeline, you should make sure that all branches having the mob/ prefix are ignored. Otherwise you might produce some unwanted builds while having a pair programming session.

I am curious about your opinion on this topic. Did you observe similar behavior regarding the use of Live Share? Have you tried out less interactive tools like Mob for remote pair programming?

Reach out to me via e-mail or social media 🙂

Next up

Want to stay up to date?