English for Remote Pair Programming: Narrating Code and Sharing Context

Remote pair programming — two engineers collaborating on code in real time over video call — demands a specific register of spoken English. You need to narrate your thinking, ask precise questions, and maintain shared context, all while writing code and managing a call.

The Driver and Navigator Roles

Pair programming uses two roles:

• Driver — the person typing code
• Navigator — the person reviewing, thinking ahead, and guiding

Understanding these roles in English helps you switch between them smoothly.

Suggesting a switch

• “Do you want to take over the keyboard for a bit?”
• “Shall I drive for a while?”
• “Why don’t you navigate and I’ll type — you have a clearer picture of the design.”
• “Let’s swap — I’ve been driving for 20 minutes.”

Handing over

• “I’m going to share my screen now — you should see the editor.”
• “Can you see my terminal? I’ll walk you through what I’m about to type.”
• “I’ll hand over control now. Use the Live Share link.”

Narrating Your Thinking

The most important skill in pair programming is thinking aloud — narrating what you are doing and why, so your pair can follow and contribute.

Narrating what you are typing

• “I’m creating a new function here to handle the database retry logic.”
• “I’m going to extract this into a separate method — it’s getting too long.”
• “Here I’m injecting the dependency rather than instantiating it directly.”
• “I’ll add a guard clause at the top to return early if the input is null.”

Narrating what you are thinking

• “I’m considering two approaches here — let me think for a second.”
• “My instinct is to use a map, but I’m not sure if that’s overkill for this use case.”
• “I’m suspicious of this timeout value — it feels too low for a network call.”
• “Let me just check whether this library handles Unicode correctly before we rely on it.”

Narrating uncertainty

• “I’m not 100% sure about the API contract here — let me pull up the docs.”
• “This is a bit of a guess — I think it works, but let’s add a test to confirm.”
• “I vaguely remember there was a bug in this area — worth checking the git log.”

Asking Clarifying Questions

Remote pair programming requires more explicit communication than in-person — you cannot point at the screen as easily.

Asking about intent

• “What are we trying to achieve with this function?”
• “Is the goal to validate the input or to transform it?”
• “Are we doing this for now or is this the final design?”

Asking about the codebase

• “Where does this get called from?”
• “Is there a test for the existing behaviour before we change it?”
• “What does UserContext contain — is it documented anywhere?”

Checking understanding

• “Just to confirm — we want the error to bubble up, not be swallowed here?”
• “So the expected behaviour is: if the token is expired, redirect to login?”
• “Am I understanding correctly that this runs synchronously?”

Sharing Context and Background

When you know something your pair does not, share it clearly:

Giving background

• “A bit of background: this module was written before we adopted the new error handling pattern.”
• “Worth knowing: there’s a known bug here — I’ll link the ticket.”
• “Context: this function is called 10,000 times per second in production — performance matters.”

Flagging a concern

• “I’m going to flag that this approach could cause issues if the network is slow.”
• “One concern: this is not thread-safe as written.”
• “Just a heads-up — we’ll need to update the migration script if we change this schema.”

Giving and Receiving Suggestions

Suggesting without taking over

• “One option would be to use a decorator here — what do you think?”
• “I wonder if a factory function would be cleaner than the constructor approach.”
• “Have you considered making this async? It might simplify the caller.”

Receiving a suggestion

• “That’s a good point — let me try that.”
• “I see what you mean. Let me refactor to see how it looks.”
• “I’d like to understand why that would be better — can you walk me through it?”

Politely disagreeing

• “I see the appeal, but I’m worried that would make it harder to test.”
• “That’s a valid approach. My concern is readability — is there a middle ground?”
• “I’d push back slightly — I think the extra abstraction adds more complexity than it removes.”

Managing the Session

Keeping focus

• “Let’s stay on track — we can refactor that later.”
• “That’s a good idea for a follow-up ticket. Let’s park it for now.”
• “We’ve been on this for 30 minutes — should we take a break or push through?”

Checking in

• “How are you doing? Is the pace OK for you?”
• “Is the audio clear? I want to make sure you can hear me.”
• “Can you see the line I’m editing? It’s line 87.”

Wrapping up

• “Let’s commit what we have and write up the outstanding questions.”
• “I’ll open a ticket for the refactor we discussed.”
• “Good session — we made solid progress on [X]. Next time let’s start with the tests.”

Key Takeaways

• Narrate constantly: tell your pair what you are typing and why.
• Think aloud: “I’m considering… my instinct is… I’m not sure…”
• Use precise questions: ask about intent, context, and expected behaviour — not just “what does this do?”
• Share background proactively: do not assume your pair has the same context you do.
• Suggest without commanding: “one option would be,” “have you considered,” not “just do X.”
• For remote sessions, over-communicate: describe what is on your screen, confirm audio, check understanding explicitly.