Build fluency in the language of collaborative, real-time pair programming.
0 / 5 completed
1 / 5
At standup, two devs mention they'll work through a tricky feature together at one keyboard today. What practice is this?
Pair programming has two developers working together on the same code, typically at one machine, combining their thinking in real time. It is often used for complex, high-risk, or knowledge-sharing-heavy tasks. This contrasts with solo work followed by an asynchronous code review.
2 / 5
During pairing, one dev writes code while the other reviews it in real time and suggests improvements. What are these two roles called?
In pair programming, the driver types the code while the navigator reviews it in real time, thinks ahead, and catches issues as they arise. Pairs typically swap these roles periodically to keep both engaged. This division of labor is a defining structure of the practice.
3 / 5
In a code review discussion, a teammate mentions the pair switched roles every 10 minutes using a timer. What practice is this?
Role rotation (sometimes called ping-pong pairing, especially when alternating writing tests and implementation) keeps both participants actively engaged by regularly swapping who drives and who navigates. Without rotation, one person can passively disengage. This structure sustains focus over longer pairing sessions.
4 / 5
An incident report shows a critical piece of business logic was understood by only one engineer, who then left the team. What practice would have reduced this risk?
Pair programming naturally spreads knowledge of tricky or critical code across at least two people, reducing the bus-factor risk of a single person being the sole holder of important context. This knowledge-sharing benefit is often cited alongside quality improvements as a reason to pair on high-risk work. It complements, rather than replaces, good documentation.
5 / 5
During a PR review, a teammate asks whether pairing on a task eliminates the need for a separate code review. What is the typical guidance?
Because pairing already involves real-time review by the navigator, some teams treat a pair-programmed change as sufficiently reviewed, while others still require a separate async review for a fresh perspective. The right policy depends on team norms and the criticality of the change. Being explicit about this expectation avoids confusion about whether a pair-programmed PR still needs approval.