Body Doubling for Developers

Programming has an unusually long load-in and an unusually easy escape hatch. Body doubling helps with one of those problems and not the other.

What the work is actually like

Development swings between holding a large mental model of a system — expensive to build, instantly destroyed by an interruption — and mechanical work where the path is already known: tests, migrations, review comments, the tickets you keep deferring.

Where presence helps

  • The backlog of small tickets you keep sliding forward
  • Tests, documentation, and cleanup nobody schedules
  • Code review, which is avoided far more than it is difficult
  • Getting started on a refactor whose shape you already understand

Where it does not — and may make things worse

This is the part most articles skip. Presence raises arousal, and raised arousal pushes you toward what you already know how to do. That is excellent for well-learned work and actively unhelpful when the job is to find something you do not yet have.

  • Architecture and design work, where you need to sit with not knowing
  • Debugging something genuinely mysterious — that needs freedom to wander, not a timer

A session that fits this work

  • Name the ticket, not the project. "Fix the flaky login test", not "work on auth"
  • Fifty or ninety minutes for anything with a real load-in; short blocks waste the approach
  • Close Slack properly rather than muting it — a muted tab is still a live option
  • Leave a failing test as your stopping point, so tomorrow starts with an obvious next keystroke

The failure mode for developers

Treating "environment setup" as the session. Tooling is endlessly improvable, always feels like work, and never ships anything. If two sessions in a row went to configuration, the next session has to touch product code.

If none of this is landing, the problem may be upstream: read what body doubling actually is, or why starting is the hard part.

Common questions

Is body doubling the same as pair programming?
No, and confusing them ruins both. Pair programming is collaboration on one problem with constant talking. Body doubling is two people on separate work in silence — the presence is the only shared thing.
Does it help with debugging?
It helps you start debugging, which is often the hard part. Once you are inside a genuinely confusing bug, the timer becomes a nuisance — let the session run over rather than breaking a live investigation.

Body doubling, elsewhere