Remote Work Tools

Mob programming — the whole team working on one thing together — sounds counterintuitive for remote teams, but it solves specific problems that async work can’t: onboarding new engineers, tackling genuinely hard problems that need multiple perspectives simultaneously, and transferring knowledge across the team. Done well, a 90-minute remote mob session on a hard problem beats a week of back-and-forth async comments.

Table of Contents

The Core Structure

Remote mob programming needs more explicit structure than in-person because there’s no shared physical space to anchor coordination.

Roles:

Timing:

The golden rule: The driver types only what the navigator says. No initiative, no “I think we should also…” — that goes through the navigator.

Tool Setup

Option 1: VS Code Live Share + Video Call

Live Share lets multiple people edit the same file simultaneously, but in mob sessions only the driver types.

# Install Live Share extension
code --install-extension ms-vsliveshare.vsliveshare

# Session setup:
# 1. Navigator shares their VS Code session
# 2. Driver joins the share — they see the code and can type
# 3. Everyone else joins as read-only observers
# 4. Rotation: driver leaves, new driver joins as editor

# Dedicated VS Code workspace for mob sessions:
# .vscode/mob.code-workspace
{
  "settings": {
    "editor.fontSize": 16,
    "editor.lineHeight": 1.6,
    "editor.minimap.enabled": false,
    "liveshare.allowGuestDebugControl": true,
    "liveshare.allowGuestTaskControl": true
  }
}

Live Share limitations:

Option 2: Tuple

Tuple is purpose-built for pair/mob programming with low-latency screen sharing and audio.

# Install Tuple (macOS only as of 2026)
brew install --cask tuple

# Start a mob session:
# 1. Host opens Tuple, invites all participants
# 2. Host shares screen
# 3. Rotation: host passes control to the driver with a click
# 4. Any participant can request control — the host approves

# Key Tuple features for mob sessions:
# - <100ms latency on good connections (vs 150-300ms in Zoom screen share)
# - Retina resolution screen sharing
# - Mouse multiplexing (multiple cursors visible)
# - Direct audio without video codec overhead

Option 3: Gitpod or Codebase (Cloud IDE Mob)

For teams across multiple operating systems or without powerful local machines:

# .gitpod.yml — shared cloud dev environment
image:
  file: .gitpod.Dockerfile

tasks:
  - name: Setup
    init: |
      npm install
      cp .env.example .env
    command: npm run dev

ports:
  - port: 3000
    visibility: public

vscode:
  extensions:
    - ms-vsliveshare.vsliveshare
    - dbaeumer.vscode-eslint
    - esbenp.prettier-vscode

Everyone opens the same Gitpod workspace URL and uses Live Share within it — no local environment required.

Tool Comparison: Live Share vs Tuple vs Gitpod

Picking the wrong tool is the fastest way to kill engagement in a remote mob session. Here is how the main options compare:

Factor VS Code Live Share Tuple Gitpod (cloud IDE)
Latency Medium (80-200ms) Low (<100ms) Depends on cloud region
OS support Windows, macOS, Linux macOS only Browser-based (any OS)
Local env required Yes Yes No
Remote terminal access Requires host permission Full control passable Built-in shared terminal
Cost Free $35/user/mo $9/user/mo (Team plan)
Best for Mixed OS teams macOS shops wanting quality Teams with complex or inconsistent local setups

Tuple is the best pure mob experience if your team is on macOS and you can justify the cost — the latency difference is noticeable in active coding sessions. Live Share is a reasonable free alternative for occasional mob sessions. Gitpod becomes the right answer when local environment inconsistency is causing mob sessions to lose 20 minutes at the start to setup issues.

Session Structure (90 minutes)

:00 — Check-in (5 min)
  - What's the goal of this session? One sentence.
  - What's NOT in scope?
  - Who's first driver/navigator?
  - Timer visible to all?

:05 — First rotation (15 min)
  Navigator: "Let's start by reading the failing test"
  Driver: types and navigates as directed

:20 — Rotation (2 min)
  Timer bell → Driver pushes WIP commit → Navigator → Driver

:22 — Second rotation (15 min)

:37 — Third rotation (15 min)

:52 — Fourth rotation (15 min)

:67 — Retrospective (10 min)
  - What did we accomplish?
  - What should we do differently next session?
  - Any knowledge gaps surfaced?
  - Next session goal?

:77 — Final commit, push, and PR (10 min)

WIP Commits for Rotation

Push a WIP commit on every rotation so the incoming driver starts with current code:

#!/bin/bash
# mob-handoff.sh — run at each rotation
git add -A
git commit -m "WIP: mob session $(date +%Y%m%d-%H%M) [$(git config user.name)]"
git push origin mob-session
echo "Handoff complete. Next driver: pull and open VS Code"

The mob session branch is squash-merged at the end with a proper commit message.

The most common failure mode in mob programming is navigator breakdown:

“Let me just type it quickly” — Navigator takes keyboard from driver. Stops the learning/discussion dynamic.

“What do you think we should do?” — Navigator asks the driver for decisions. The navigator decides; driver implements.

Monologue navigator — One person dominates navigation across rotations, turning it into pair programming with an audience. Explicitly require silent time for mob members to surface ideas.

Too much detail — “Type async def create_user open paren user: UserCreate close paren arrow UserResponse colon” — overly granular. Navigate at intention level: “Let’s create the async endpoint for user creation with the standard signature.”

Keeping the Mob Engaged

The biggest practical challenge in remote mob sessions is maintaining mob engagement. Mob members who aren’t driving or navigating can zone out within minutes — and in-person cues like someone leaning forward or reaching for the keyboard don’t translate over video.

Concrete techniques that help:

Rotate every 15 minutes without exception. When people know their turn is coming, they stay attentive. Longer rotations let attention drift.

Assign an explicit “mob voice” role. One mob member is designated to speak up with observations, questions, and alternatives at any time. This role rotates with each handoff. It gives permission to people who might otherwise stay quiet.

Use shared scratch space. Keep a collaborative document (Google Docs, Notion, or a shared terminal session) where mob members can write down ideas, questions, or alternative approaches they want to raise at the next pause. This captures thoughts without interrupting the navigator-driver flow.

Run shorter sessions more often. A 60-minute mob session with full engagement is more productive than a 2-hour session where the second hour is low-quality. Schedule 60-90 minutes maximum and book follow-up sessions for complex problems. Ending while the team is still energized is a reliable way to build momentum for the next session.

When Mob Programming Is Worth It

High value:

Low value / avoid:

Tools for the Timer

# Terminal timer (visible to driver who shares screen)
# Install: brew install terminal-notifier
countdown() {
  local seconds=$1
  while [ $seconds -gt 0 ]; do
    echo -ne "\r\033[K⏱ $((seconds/60)):$(printf '%02d' $((seconds%60))) remaining"
    sleep 1
    ((seconds--))
  done
  terminal-notifier -title "Mob Session" -message "Rotation! Switch driver."
  echo -e "\r\033[K🔔 Time's up! Rotation."
}

# Start 15-minute timer
countdown 900

Web-based alternatives:

Session Notes Template

## Mob Session — [date]

**Goal:** [one sentence]
**Attendees:** @alice (nav1), @bob (driver1), @carol (driver2), @david (nav2)
**Duration:** 90 min

### What we built / decided:
- [specific outcome]

### Decisions made (link to ADR if significant):
- [decision and rationale]

### Knowledge transfers:
- @alice: explained the payment retry logic to @carol
- @david: unfamiliar with the test fixture setup — explained during session

### Follow-up items:
- [ ] #456 — refactor the session above into a clean PR (owner: @alice)
- [ ] Write tests for the edge case we discovered (owner: @bob)

### Next session goal (if applicable):
[what we'd tackle in a follow-up session]

Explore Our Developer Guides

© 2026 theluckystrike Developer Guides