#4 - TDD, Pair Programming, and Katas: How Driver and Navigator Work in Pair Programming?
Sometimes, you might feel your team takes too long to share and discuss ideas during Pair Programming. But Pair Programming is not just about two developers working on the same code; some rules help you be productive. By specifying the role of the Driver and Navigator, you might overcome endless debates while saving time. In this article, I'll dive deep into these concepts and how they can improve Pair Programming techniques.
The difference between a Driver and a Navigator when doing Pair Programming
When doing Pair Programming, both developer ideas may often clash if there are no clear rules, causing the flow of development to be interrupted. The team can resolve this issue by letting one of the developers take control and drive the implementation. The driver is responsible for implementing the code, refactoring it as necessary, taking command of its syntax, and ensuring its readability. The other developer is responsible for monitoring each line of code written and alerting the driver for any potential bug or misspelling, sharing thoughts on each commit, and letting the driver know what comes next.
Tips and tricks on Pair Programming
Make the communication between the driver and navigator as smooth as possible. Let the driver code as he explains what he's doing so the navigator can understand the implementation. The navigator should keep notes of ideas they can share between each commit and avoid interrupting the drive as it may lose the trail of thought. When the team doubts an implementation, you may time-box any discussions to resolve any dispute on which way to go. Take an experimental approach to observe different solutions, pick the best one, and apply tests to make it easy to change the team's mind anytime.
Avoid Parent-Child Pair Programming anti-pattern!
Teams use Pair Programming for effective knowledge transfer, but when a senior and a junior pair, it's easy for the senior developer to give too many detailed instructions, transforming recommendations to commands and limiting the junior's capacity to grow. Avoid The Parent-Child anti-pattern. Let the junior developer grow and develop his solutions; let them "learn" not to "fail."
Conclusion
In this article, we have defined the Driver and the Navigator in Pair Programming, their difference, some suggestions on how to apply them, how to avoid a common pitfall, and why defining these roles is essential for smooth communication and productivity.
