Great post! 😃
I particularly liked that you acknowledged that pair programming has a humane aspect to it. This is sometimes so hard to justify to businesses. The Engagement factor is vital and pair chemistry is quite often overlooked and doesn't get factored.
Having pair chemistry makes a huge difference in your development experience and your ease of getting accustomed to pair programming. The difference between a good pairing session and a bad pairing session is the chemistry you share with your pair. But this could quite easily become a pitfall, if you're not careful about it.
In addition to spreading the load, pair programming also greatly accelerates spreading of context/knowledge to the entire team on top of building accountability and collective ownership of the codebase. On-boarding someone to the team is much more easily accomplished through pair programming. If you're new to the team, getting familiar with the codebase can be daunting and time-consuming, particularly so if the other people on your team aren't in a position to take time off developing stories. Pair programming is a great way to get familiar and comfortable with the codebase.
I agree with you that the driver/navigator model could get tiresome/boring after a while. And I prefer the ping/pong model, mainly because we are focused on Test Driven Development (TDD). One of you would write a test, the other person writes just enough code to make the test pass and writes another test. The first person now writes just enough code to make the test pass and writes another test. This repeats until you've exhausted all possible test cases. 🏓
Pair programming has its own share of pitfalls if done wrongly. Frequent pair switching is essential. Else you could so become accustomed to the other person's style that you start thinking alike and possibly missing out on the peer review/feedback that pair programming offers. Switch pairs often. Also, switching greatly increases agility in developing chemistry with a pair.
Thank you for this well thought out response. Every pair has their own preference on how to work together. There are so many ways to go about it. I think that the driver/navigator model is great if you are new to coding. You get to practice different parts of the process as well as plenty of guidance and support. Learning how to explain your code is also practiced with this model and that can go a long way when working with teams.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great post! 😃
I particularly liked that you acknowledged that pair programming has a humane aspect to it. This is sometimes so hard to justify to businesses. The Engagement factor is vital and pair chemistry is quite often overlooked and doesn't get factored.
Having pair chemistry makes a huge difference in your development experience and your ease of getting accustomed to pair programming. The difference between a good pairing session and a bad pairing session is the chemistry you share with your pair. But this could quite easily become a pitfall, if you're not careful about it.
In addition to spreading the load, pair programming also greatly accelerates spreading of context/knowledge to the entire team on top of building accountability and collective ownership of the codebase. On-boarding someone to the team is much more easily accomplished through pair programming. If you're new to the team, getting familiar with the codebase can be daunting and time-consuming, particularly so if the other people on your team aren't in a position to take time off developing stories. Pair programming is a great way to get familiar and comfortable with the codebase.
I agree with you that the driver/navigator model could get tiresome/boring after a while. And I prefer the ping/pong model, mainly because we are focused on Test Driven Development (TDD). One of you would write a test, the other person writes just enough code to make the test pass and writes another test. The first person now writes just enough code to make the test pass and writes another test. This repeats until you've exhausted all possible test cases. 🏓
Pair programming has its own share of pitfalls if done wrongly. Frequent pair switching is essential. Else you could so become accustomed to the other person's style that you start thinking alike and possibly missing out on the peer review/feedback that pair programming offers. Switch pairs often. Also, switching greatly increases agility in developing chemistry with a pair.
Thank you for this well thought out response. Every pair has their own preference on how to work together. There are so many ways to go about it. I think that the driver/navigator model is great if you are new to coding. You get to practice different parts of the process as well as plenty of guidance and support. Learning how to explain your code is also practiced with this model and that can go a long way when working with teams.