

Ask HN: Pair programming anti-patterns? - devmonk

The following are some pair programming anti-patterns" (ok, maybe just bad behaviors) that I've noticed:<p>1. Prematurely trying to optimize code.<p>2. Long unrelated discussion. (Note: this one you just have to let go and accept, or you risk #3.)<p>3. Being anti-social.<p>4. <i>Always</i> 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.)<p>5. Not listening to your pair partner because you are too busy doing something else.<p>6. Not doing what you said you'd do/doing more than you said you'd do.<p>7. Just not communicating.<p>8. Not ping-pong'ing/both partners not staying active (which results in zombie state).<p>9. Listening to partner, but ignoring feedback, as if they are an annoying popup in your IDE.<p>10. Providing too much (esp. negative) feedback to partner.<p>Those are just a few. What pair programming anti-patterns have you experienced?
======
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.

------
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

