Ask HN: Does pair programming make one of programmers lazy?
6 comments
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.
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.
The only way I've found pair programming to work is if you have a junior dev drive, and a senior dev "coaches" them.
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.
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.
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
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
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.
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.
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.
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.
How did you mitigate or improve this situation?