I like pair programming. Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day

I like pair programming. Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day when you have your better, etc. I set limits on pair programming. It seems to me 4 hours of true focus is a limit for most people on most days and pair programming requires constant focus whether you are driving or observing. Other 4 hours are left for administrativia, some other smaller tasks, personal learning, making up for the stuff you were too embarrassed to ask during session, etc. -- As to comments that talking constantly breaks your concentration and slows you down -- yes, it does and at the same no, it does not. It is just a different way to achieving the outcome. If you are programming alone you have better ability to focus, you can start/end when it is suitable for you, you don't need to consult every single part of design. But what is left is that you are making mistakes on your own (and the longer it is uncorrected the higher the cost of fixing it) and there is no other person that knows how the stuff you developed works. So while you yourself program a little bit slower, you are also achieving other goals concurrently with writing the code -- getting it honestly reviewed, passing knowledge, etc. I have also found that verbalizing and explaining what I do many times causes me to find issues that I could have probably missed. -- I personally like pair programming especially when I want to transfer some of the techniques and reasoning I use when developing solutions. This is not something that can be passed through presentations or reading and explaining the code.