On Pair Programming

Hello everyone, sadly, this is the last blog for a while. To anyone readying this, thank you for keeping up with this badly written blogs. 

Today, we are going to talk about pair programming, this working framework that is widely used in the software industry. Some benefits include: Knowledge sharing, reflection, code review "on-the-go", focus, collective code ownership, team flow and most important, quality.   So everything is good, right?  Pair programming should be used always to improve software quality. Well, yes, but actually, no. It has also some challenges that most times are left apart, and personally, I didn't bother to think of them.  I'm only going to talk about the ones that I found most relevant, you can check the whole reading here.

Exhaustion, pairing can turn your own times upside down, maybe you like to take breaks every hour or so, but your partner prefers to finish the work first and then take a rest. So we have a problem. You and your partner need to talk about this at the beginning and work something that is good for both. 

Different skill levels, if one feels that is better that the other it can lead to a difficult time for both. Or if someone just do what the other says without questioning anything. 

Pairing with someone with different hierarchic. I haven't experienced this, but I could see why this one is the hardest. 

The best way to tackle this, and in general, any problem, is to communicate with your partner. Talked about everything because you guys are going to work for the same goal, so if you have a better understanding of each other, the whole process is going to go smoothly. And always have a mindset of you can learn new stuff, maybe think that you like, or maybe things that you don't, but there is always something to learn.