I guess I'm just not the pair programming type. I find that the experience is usually frustrating.
1. Most software development occurs in my head. If you watch me "write" software, you'll see me sitting silently at my desk most of the time. I only actually type once I have a solid picture of the problem and solution (except for the occasional exploratory code to coax out more details from the problem domain). I can't do that with someone talking and changing the existing code structure. It's basically having someone constantly interrupt you. I'm not a multitasker; I can't write code and converse with someone at the same time.
2. I tend to jump around a lot in an existing codebase to verify behaviors or gain a better understanding of a subsystem. But the person next to me doesn't have the same mental map, and so what I'm doing will appear almost random. I've tried explaining as I go, but it just serves to muddy the waters because the other person will be talking and interrupting as I'm trying to keep the delicate mental structure intact.
I much prefer to work alone, and then bounce ideas off colleagues when I'm stuck.
I'm not keen on pairing, but instead of planning things in my head, that's why I do TDD. The tests explore various ideas (as in effect the tests are clients of whatever I'm building, just like the finished app will be) so I get to play around with it before writing any code.
There are benefits to be had by BOTH. Pairing 100% of the time works well for Pivotal and their clients. At AirPair we mix and match for appropriate tasks internally. Externally for our customers, we use it as the ultimate format of knowledge share and training.
Benefits of solo:
- Creative
- Code faster (in terms of lines, no necessarily quality)
- Get to do things they way you like
Benefits of pairing
- Instant code review and double vetted architecture decisions
- Avoid distractions (like email/social media) as you can't be rude to your pair
- Getting accelerated knowledge infusion on both software tricks and domain of the application
I agree. I tried to pair program for a few years. Most people will tell me how it is my fault pair programming is not working, but I just don't like it.
I find myself starting to zone out when working with someone who types slow, has odd habits (such as checking twitter or email too frequently), uses a different editor than I, or we have a large skills gap. I know there are techniques to solve some of these, but again, I personally don't like it.
I much prefer a gated review system, such as gerrit.
1. Most software development occurs in my head. If you watch me "write" software, you'll see me sitting silently at my desk most of the time. I only actually type once I have a solid picture of the problem and solution (except for the occasional exploratory code to coax out more details from the problem domain). I can't do that with someone talking and changing the existing code structure. It's basically having someone constantly interrupt you. I'm not a multitasker; I can't write code and converse with someone at the same time.
2. I tend to jump around a lot in an existing codebase to verify behaviors or gain a better understanding of a subsystem. But the person next to me doesn't have the same mental map, and so what I'm doing will appear almost random. I've tried explaining as I go, but it just serves to muddy the waters because the other person will be talking and interrupting as I'm trying to keep the delicate mental structure intact.
I much prefer to work alone, and then bounce ideas off colleagues when I'm stuck.