Pairing & Mob Sessions for Go Teams

Knowledge transfer patterns for idioms and concurrency.

Go idioms are learned through feedback loops on real code.

Structured pairing and mobbing compress months of trial-and-error into focused sessions that also spread review culture.

Summary

Pairing and mobbing are deliberate formats for sharing toolchain habits, error-handling patterns, and concurrency review judgment.

They complement reading paths and checklists with live explanation of why a reviewer would block a PR.

Short sessions with clear agendas outperform unstructured screen sharing.

Recipe

Quick-reference recipe card - copy-paste ready.

## 90-minute onboarding pair (template)
 
1. (15m) Navigator walks module layout + CI README
2. (25m) Driver fixes one golangci-lint issue with navigator coaching
3. (25m) Joint read of one concurrent code path; run go test -race
4. (15m) Debrief: three idioms to apply + one PR to open before next session
5. (10m) Schedule next session + assign pre-read link

When to reach for this:

• First two weeks of Go onboarding for experienced hires
• Before a engineer's first concurrency-heavy PR
• After an incident to replay timeline and tests
• When review comments repeat the same idiom gap across multiple authors

Working Example

A team runs a weekly concurrency mob on a staging bug: elevated goroutine count after deploy.

// Mob examines this pattern together - driver shares screen
func (s *Service) poll(ctx context.Context) error {
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-time.After(time.Second):
            if err := s.tick(ctx); err != nil {
                return err
            }
        }
    }
}

// Refactor outcome the mob aims for - ticker with defer Stop
func (s *Service) poll(ctx context.Context) error {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-ticker.C:
            if err := s.tick(ctx); err != nil {
                return err
            }
        }
    }
}

What this demonstrates:

• time.After in loops allocates timers; idiomatic fix uses NewTicker and Stop.
• Mob reads production metrics first, then code, then writes a regression test.
• Navigator asks driver to run go test -race before merging the fix.
• Session notes link to the PR and update a team gotchas doc.

Deep Dive

How It Works

• Driver owns keyboard; navigator asks questions, spots missed errors, and cites team standards.
• Mob extends to 3+ people with one driver rotating on a timer; best for incidents and design spikes.
• Sessions should end with artifacts: PR link, checklist update, or ADR bullet - not only verbal agreement.

Session Types

Go Notes

// Pairing drill: table-driven subtest skeleton reviewers expect
func TestLimiter(t *testing.T) {
    cases := []struct {
        name string
        n    int
        want int
    }{
        {"zero", 0, 0},
        {"one", 1, 1},
    }
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            if got := Limiter(tc.n); got != tc.want {
                t.Fatalf("got %d want %d", got, tc.want)
            }
        })
    }
}

Use drills like this when review feedback says "add cases" but the author has not seen exemplar tests in your repo.

Facilitation Rules

• Rotate roles every 20-30 minutes in mobs.
• Silence phones; one conversation at a time.
• Park unrelated refactors in a "later" list visible to the group.
• Prefer repo tasks over synthetic kata after week one so imports and CI match reality.

Gotchas

• Unbounded mob without agenda - sessions decay into passive watching. Fix: publish a three-bullet agenda before calendar invite.
• Same senior always navigates - creates single-point review culture. Fix: rotate navigators monthly.
• Skipping -race during concurrency pairs - hires think green tests mean safe concurrency. Fix: make race run a session exit criterion.
• No written follow-up - insights die when people switch tasks. Fix: two-minute debrief note in ticket or wiki.
• Pairing only juniors - seniors also need pairing when touching unfamiliar domains (operators, WASM). Fix: schedule cross-level pairs on new stacks.
• Recording without consent - violates policy or comfort. Fix: ask explicitly; default to written notes only.

Alternatives

FAQs

Related

• Onboarding Go Specialists - where pairing fits in ramp layers
• Team Onboarding Basics - example 9 pairing agenda
• Go SME Onboarding Checklist (30/60/90) - pairing evidence rows
• Code Review Culture for Go - norms pairs should teach
• Effective Go Reading Path - pre-read spine between sessions

Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).