HN Explorer

Ask HN: Pair programming anti-patterns?

2 points by devmonk ↗ HN
The following are some pair programming anti-patterns" (ok, maybe just bad behaviors) that I've noticed:

1. Prematurely trying to optimize code.

2. Long unrelated discussion. (Note: this one you just have to let go and accept, or you risk #3.)

3. Being anti-social.

4. Always not sharing the screen. (e.g. Pair partner brings a macbook and then basically proceeds to program as if they aren't sitting next to you.)

5. Not listening to your pair partner because you are too busy doing something else.

6. Not doing what you said you'd do/doing more than you said you'd do.

7. Just not communicating.

8. Not ping-pong'ing/both partners not staying active (which results in zombie state).

9. Listening to partner, but ignoring feedback, as if they are an annoying popup in your IDE.

10. Providing too much (esp. negative) feedback to partner.

Those are just a few. What pair programming anti-patterns have you experienced?

2 comments

[ 3.2 ms ] story [ 16.0 ms ] thread
lzw
Pairt programming for more than 20 minutes at a time. The best pair programming experience i've had was when it was occasional and my boss or another engineer would come over or I would go to them and we'd work on a bit of code together where the combined expertise of the two of us was more Than either of us alone. This made it very productive to solve integration problems or implement specific algorithms. The rest of the time, i can think faster than I can type. So, for me, pari programming works best as ashore term thing, and in posing it or trying to do it all days an antipatternl
vogon
Difference in skill levels makes one lose heart because they can't do what the other can. Then they get passive. They forget they can still contribute on different things.