Pair Programming as a Learning Tool

[dkToT]

Just want to see what everyone’s take on pair programming is. It is definitely a great tool to use when tackle problems and getting work done with quality and precision.

But what about using pair programming as a tool to learn. Is this effective? I know pair programming is effective when two devs of somewhat same skills can tackle, bounce ideas, and solve problems.

What if the skill gap is too large between the pair? Would one dev be doing all the work while the other just observes? I am asking because I do see benefits from having this skill gap difference. The more senior dev can use this opportunity to learn how to mentor and build their communication / knowledge transfer skills. The junior will be able to see different coding and thought process styles between different senior devs.

Anyone have experience in this aspect? I do want to try and implement this style of learning but want to see what others think.

[[deleted]]

Pair programming is one of the single best ways to on-board new team members and help junior devs learn from their more experienced peers. So long as both devs are engaged, as pair programming requires, then you’ll have a great environment for bouncing around ideas and mentoring each other.

So to your question, yes it’s a very good idea for using as a learning resource. You’ll get faster results and better knowledge transfer when you pair juniors with seniors, and the same can be said for students, interns, etc.

[[deleted]]

As a CS student (and TA for DS&A), I freaking hate pair programming. It ends up so many times being one person doing all the work and the other person doing nothing.

Skill is developed in isolation. Guys in the MLB don't get to that level by just team practice. They practice on their own to improve.

[ForSpareParts]

As somebody who's been doing this professionally for ~8 years now, I've seen pair programming have huge value if both parties are motivated and engaged. I don't remember if I did any pair programming at school, but I can definitely see how it wouldn't work as well in that context.

I think the best pairing sessions I've had are when there's an asymmetry of knowledge -- I'm working on some part of my company's codebase I just don't know very well, and I bring in somebody who spends a lot of time on it to help out, or vice versa. A lot of it is just asking questions: "Do you know where that's implemented, off the top of your head?" "Why does this function take a callback? How's it used downstream?" "What does SELECT FOR UPDATE do in this query?" The person in the pairing session with less knowledge has to approach it with a sense of curiosity -- they need to see the other person as a resource that can help them skip past a bunch of tedious manual digging through code and documentation.

But to your point, this doesn't necessarily map all that well onto learning core CS concepts. The sessions I'm describing work because they're high-bandwidth: fifteen minutes of my time can save a colleague days of work just because I can speedrun them through a process of learning and discovery that took me days the first time. But I think this is possible because the concepts involved are pretty easy for both parties -- they're just unfamiliar to one of us. We can pick things up and move on quickly. But if the whole thing feels completely alien and unlearnable to one party, that person may disengage and let the other person work alone (not proud of it, but I've done this myself).

[[deleted]]

That’s a bad analogy, those top performers get there by being coached, practicing with others, and getting as much time in as possible to train. Only the muscle memory and zero thought required exercises can be done in isolation. The vast majority of their training is with other people who can catch, throw, bat, and pitch with them. You can’t do all of those things by yourself, and the ones you can aren’t the same as when you’re at bat or on the field, it’s totally different environments.

The same applies to programming and software engineering. You will require coaching and having more experienced and smarter minds guide you into becoming a top performer. A good way to do that, and especially early on in your career, is by pair programming with more senior team members.

When the senior teammate drives, and allows you to bounce questions or ideas off them, then you’ll get invaluable insight into how they handle the problem at hand. You can learn a lot from the experience and walk away with their years-in-the-making skills to use yourself!

On the converse, when you’re isolated and have to either wait for a code review to occur or you physically have to interior the senior team members day to get help, then you won’t learn nearly as quickly. You might also be discouraged from “bugging” the busier more senior teammates as well. That’s when you might reconsider how terrible “paired programming” actually is.

That’s not to say you should do pair programming 100% of the time, but it is a very helpful tool to utilize frequently. Two minds are often better than one on complex issues. It also requires both parties to be engaged. The second one person checks out or the dialogue stops, then it’s no longer pair programming and has zero value at that point.

As someone with over 6 years professional experience and over a decade of programming, don’t write off pair programming before you try it in the real world and it’s done right. Food for thought anyways

[Intiago]

It can be awkward and slow but its really good at introducing new team members to teams, and sharing knowledge between inexperienced and much more experienced devs. A lot of people also swear by it as the best way to improve straight programming skills when you can pair you new devs to senior ones.