4 ms·

I've done pair programming. With the right partner it is productive and produces better code. The person at the keyboard is at a disadvantage because the partne

by daly 10y ago

I've done pair programming. With the right partner it is productive and produces better code. The person at the keyboard is at a disadvantage because the partner has more "think time". Anyway, I found it pleasant. The KEY problem is management. My partner always wanted to type so we ended up with me doing the thinking/review while he worked out the syntax. When we got our performance reviews my partner got a raise and I got a bad review. My manager believed that he did all the work and I just sat around talking. Beware the 'review' trap...

wwwater 10y ago
So you could concentrate and think despite that there is another person sitting next to you and waiting when you say something? This part remains me too much of an interview: somebody sitting next to you and waits in the real time when you say something. It is too much pressure for me, somehow.
- daly 10y ago
  We both knew the task, having designed it before we started. It involved networking so there were standards we had to follow. He wasn't 'waiting', just writing code. However, writing code takes up a lot of head-space. My portion involved things like real-time code review, discussing design decisions such as where to check for edge cases, etc. There isn't much benefit to pair programming. It does catch errors sooner. It does help structure code better. It does eliminate typos the compiler can't catch. So it does have benefit. But I think the cost of two programmers does not justify the benefit. The real problem is 'shared credit'. Remember those school projects where 2 or 3 people worked together? I had one in grad school where I ended up writing almost the whole project myself but we all got an 'A' grade. Management has no way to figure out how to allocate credit. This is a problem in shops where they put people on a scale of 1-5 or some such nonsense. If your shop does this, do NOT pair program.

by daly 10y ago

wwwater 10y ago

So you could concentrate and think despite that there is another person sitting next to you and waiting when you say something? This part remains me too much of an interview: somebody sitting next to you and waits in the real time when you say something. It is too much pressure for me, somehow.

daly 10y ago
We both knew the task, having designed it before we started. It involved networking so there were standards we had to follow. He wasn't 'waiting', just writing code. However, writing code takes up a lot of head-space. My portion involved things like real-time code review, discussing design decisions such as where to check for edge cases, etc. There isn't much benefit to pair programming. It does catch errors sooner. It does help structure code better. It does eliminate typos the compiler can't catch. So it does have benefit. But I think the cost of two programmers does not justify the benefit. The real problem is 'shared credit'. Remember those school projects where 2 or 3 people worked together? I had one in grad school where I ended up writing almost the whole project myself but we all got an 'A' grade. Management has no way to figure out how to allocate credit. This is a problem in shops where they put people on a scale of 1-5 or some such nonsense. If your shop does this, do NOT pair program.