HN Explorer

Ask HN: Does pair programming make one of programmers lazy?

2 points by j32fun ↗ HN
Has anyone who has done pair programming felt like the other programmer is slacking off and just sitting in the seat like a passive passenger?

How did you mitigate or improve this situation?

6 comments

[ 4.4 ms ] story [ 23.3 ms ] thread
robinanil
Why do you do the pair programming in the first place?

What is the motivation? Are you forcing the other person to sit there, because pair programming is some kind of mandate? Or is that person wanting the pair session because they want to learn?

Question the motivation of the person and change process to fit, not the other way

j32fun
Most often it's to try and help the other person become a better programmer. I've found that people who have little desire to improve end up sitting there regardless.

The underlying desire to do it, of course, is to give the programmer (the one who we're investing in to improve) a chance to improve. It feels, however, like a wasted effort.

robinanil
I see, often the person who has little desire to improve needs to be handled differently.

There are various ways to handle low performance, including talking to the person, finding out the reason behind the low performance. Most often it is caused by external factors.

Pair programming or any such coaching tool IMO are effective only after you dig deep into the reason behind low performance. Once the individual is ready to improve, that is when you can employ pair programming.

CuriouslyC
The only way I've found pair programming to work is if you have a junior dev drive, and a senior dev "coaches" them.
j32fun
Yes, my gut is telling me the same thing too. The junior dev needs to be motivated (out of the box motivated) to learn and improve. If that isn't there, no amount of coaching/pair programming will help.

It's depressing. Sometimes it's not the lack of mentorship but the lack of motivation on the part of the student. It's almost like someone stuffing a gold coin in one's pocket and that person refusing to take it because it's too far or he can't be bothered.

enkiv2
Generally speaking, you should be swapping roles periodically.

In my experience, it works best if the person sitting is performing the planning aspects, while the person standing is critiquing or looking for bugs/typos.

If there's too much of a difference in experience level between the two people doing pair programming, I don't see the point -- it's not very effective as a didiactic tool, compared to throwing a junior engineer at a problem way over their head and waiting until they figure it out themselves.

That said, I sometimes get a lot out of performing the 'coaching' role for someone who has a lot more experience than I do, if they generally aren't good at explaining their logic, because it provides me the opportunity to ask very specific questions with very clear context about how and why they are making particular decisions. Sometimes, such questions reveal the logic behind behaviors that were learned through experience and never consciously considered yet have big ramifications on performance, code structure, or engineer effort.