December 8, 2023 • 3 min read, The Best tool to Boost Learning from Pair Programming on your day to day projects

Rédigé par Jérémy Marchand

Jérémy Marchand


  • Pair programming is a cornerstone for team and code continuous improvement.
  • As a developer, it is more efficient and more satisfying to use you own setup
  • Most of the time, you want to do pair programming with a project’s co-developer / tech lead
  • Using has very low config overhead, considering that all mobbers have access to the same remote code repository (Github, Gitlab…)

For over a year, I've extensively engaged in both mob and pair programming, and I've discovered an efficient way to do it!

The focus of this article will primarily be about pair programming, but the same concepts are applicable to mob programming (more than two people at the same time). We will explore several key areas:

  • The Effectiveness of Pair Programming: A detailed examination of why pair programming is a powerful tool for learning and development.
  • Personal Setup for Efficiency: The advantages of using one's own setup to maximize work efficiency in a pair programming environment.
  • Simplification through An exploration of how streamlines the pair and mob programming processes, making them more accessible and manageable.

There is always some space to learn code best practices

Pair programming is a software development technique where two developers work together at one workstation. One, known as the "Driver," writes the code. The other, the "Navigator", reviews each line as it's typed, providing on-the-spot quality control and suggestions. At regular intervals, both developers swap their roles.

This collaborative approach is important for several reasons:

  1. 2 brains >> 1 brain: it often leads to higher code quality by catching errors early and encouraging best practices.
  2. Learn beyond code: it facilitates knowledge sharing between more experienced and less experienced team members, thereby leveling up the skills of the entire team that goes far beyond code writing. You want to share setup tips (IDE, package managers, cool shortcuts…), debugging techniques or new design patterns
  3. Improve the pace: pair programming can actually speed up the development process. When pairing experienced dev with a rookie, you will avoid the rookie to waste precious time on some basic yet not mastered problems. There is no need to learn in pain, drowning into your dirty error log’s stack trace.
  4. It’s fun: it is about team communication, cohesion, and trust, towards unified, stress-free and relaxed work environment.

There is no One developer setup to rule them all

Using your own developer setup has several advantages, which might make it preferable over iterating on the pair's machine or using collaborative tools like VSCode Live Share. And that’s even true when you go for a pair programming session.

  1. You know your setup: Developers often spend time customizing their IDEs, terminal setups, and other tools to suit their workflow. Working in a familiar environment can increase productivity and comfort. One of my tech lead was using a different keyboard layout + Neovim in VSCode. Each keystroke was leading to anything but what I was trying to achieve.
  2. You want to improve your setup: If you always use VSCode Live share as a guest for instance, you will not even be aware of some setup made by your pair’s on his machine (extensions, cli tools, librairies…). By pair programming on both environments, you will make sure your setup is up to date and efficient for what you are doing. manages efficient coding sessions in a very seamless way

Disclaimer: I have no affiliation with the team. However, as someone passionate about efficient coding practices, I've become a great enthusiast of their tool, especially for its role in enhancing pair programming experiences.

I realized that most of the pair programming sessions I did were with people on the same projects as me (from a rookie dev to a tech lead). Given that the only prerequisite to using is shared access to the same remote repository (like GitHub or Gitlab), it implies that on your day-to-day projects, this requirement is almost always met. is THE tool that enables each developer to iterate on his machine, but on a single code base.

Install mob on a unix based machine

curl -sL | sh

Start the session and start coding

On your favorite repository, the first Driver starts the mob session. This creates a WIP mob branch from the current branch (in the example, my current branch is feat/beat-rustlings so it created mob/feat/beat-rustlings).

mob start --create
pair programming session start
mob start --create

Most of the setup is done, you can set a timer (in minutes):

mob timer 10

You can now start programming. YES, it is as simple as that.

Carry on with sharing & learning

Once the ten minutes are over and the first Driver is done, add all the local changes and push it on the remote mob branch by simply running:

mob next
code program pair programming
mob next

Now, the Driver and Navigator can switch roles, and the new Driver just has to move to the current or mob branch. To add the new Driver to the mob session and start developing, run:

mob start
pair programming learn code
mob start

As we can see, Emilio and I switched roles !

Then, to carry on, you can run mob next and mob start again to switch roles again and again.

Finalize the changes

Once you are done, all the changes will automatically be merged into the initial branch (in my case it is feat/beat-rustlings). I usually use the --no-squash option to keep the commits made on the mob branch as they are: clean committing is a skill you want to improve during pair programming. All other changes made on the mob branch are staged in the initial branch so you just have to commit and push following your usual git flow.

mob done --no-squash
pair programming finish session
mob done --no-squash

Happy collaborating!

Are you looking for Data Engineering Experts ? Don't hesitate to contact us!

If you are still willing to improve your efficiency as a developer, you can read the following article on Github Copilot

Cet article a été écrit par

Jérémy Marchand

Jérémy Marchand