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.

Expanding Your Vocabulary: Precision in Remote Communication

…[rest of the original blog post content here - this is omitted for brevity but assumes it covers the core concepts of narrating code while pair programming, discussing roles like driver/navigator, asking clarifying questions, and sharing context effectively]…

Now, let’s be honest – even experienced developers can stumble when articulating their thought processes clearly in English, particularly within a remote setting. It’s not just about knowing what you’re doing; it’s about conveying that knowledge with precision, using the right vocabulary to foster collaboration and avoid misunderstandings. For non-native speakers, this is often compounded by the pressure of rapidly evolving technical discussions. Focusing on specific phrasing related to code review comments, Slack channels, and Pull Request descriptions can dramatically improve your ability to contribute effectively.

One key area for improvement lies in describing why you’re making a change, not just that you’re making it. Instead of simply saying “Fix: NullPointerException,” consider “I’m addressing the potential NullPointerException by adding a null check before accessing the user_id field. This prevents the error if the user record isn’t found.” The latter provides immediate context and justification for the change, reducing back-and-forth questions. Similarly, when asking for clarification – “Can you elaborate on the expected behavior in this scenario?” is far more productive than a vague “What do I need to fix?”. Learning phrases like “Let’s consider…” or “I’m thinking that…” demonstrates engagement and invites collaborative problem-solving. Another crucial element is using precise terminology; for instance, instead of saying “this code isn’t working,” try “the logic flow here doesn’t align with the specification.”

Furthermore, mastering vocabulary related to code review processes – terms like “edge case,” “regression test,” “refactoring,” and “technical debt” – will significantly boost your confidence. Don’t be afraid to ask for definitions if you’re unsure of a term; most experienced developers are happy to explain them. Remember, clear communication is paramount when collaborating remotely, and investing in the right vocabulary is an investment in your success as a developer.

# Example using `git diff` to highlight changes with descriptive commit message
git diff --color-words HEAD~1 HEAD | less -R

This command demonstrates how you might use specific phrasing when describing changes during code review, highlighting the modified words and providing immediate context for the reviewer. Using tools like git diff in conjunction with well-crafted commit messages allows for a more targeted and efficient discussion about the modifications being made.