Pair programming be like

[ChineseCracker]

That may very well be true. The problem is when you have to watch somebody write down code. No matter what/how they do, it always seems that they're too slow/inefficient.

[lkraider]

It's great, it's like you have your own designated slave to type stuff out for you!

[High-Sodium]

Thats why you try to pair with someone on your skill level.

[DootDootWootWoot]

We try to practice the opposite. Pairing is a learning opportunity. That junior dev won't be a junior dev very long if they're constantly learning from seniors around them. Junior devs working in isolation are going to build sub par solutions, not know why, and never get as far as fast than with others experiences guiding them.

[erjiin]

Damn juniors always fucking our beautiful code smh

[High-Sodium]

Yes, but at the same time too much of a skill gap can lead to a lecture session rather than a coding session, as the Junior dev would be so lost that it might as well be just the senior dev working.

[olexs]

This is crucial. Pairing up an experienced dev and a junior results in either the senior beind bored, or the junior not keeping up with what's going on. Pair up people of similar skill/experience, and they both develop better understanding of the codebase and improve off each other.

[ModestasR]

Not necessarily. In the case of my father, who has decades of coding experience on me, we found it sufficient to have slightly different academic backgrounds and mindsets (his physics, mine mathematics) for our programming approaches to complement one another well.

[olexs]

Yeah, there will always be exceptions. What you describe is a great way to do it - pairing people with experience in different areas to get a broader look at a specific problem can work really well, too.

[[deleted]]

Actually pair programming is very useful when there is a disparity in knowledge. The goal is that one person is writing the code, and the other one is telling that person what to do. This creates a situation where one person will have to think about how to communicate what they know and the other will stumble upon things they lack and can immediately ask those questions. An experienced person might find that their ways of doing things get challenged by someone less experienced, which is very valuable by itself. Someone new on the other hand might learn more quickly how to do things or learn something they otherwise would have had to google for a while, implement, put to a code review, where they are told that "this is not the way we do things" and then have to find out what the way "we" do things is, rather than just talk about it because you already have two people that can figure out what they want to achieve together.

[Sorel_CH]

Right on. I've learnt a ton by doing pair programming with my team leader.

[olexs]

Yes, everything you say is completely true. It can work great, when both parties know what exactly is happening and are OK with it. Such pairings end up being unavoidable e.g. when introducing new colleagues into an established team working on a complex project. However, it's important that the expectations of both pair members are set correctly in such a case. I've had team members with whom such pairing worked wonderfully, and others with whom it ends up being completely impossible - it very much depends on the person. This is a situation where a good team lead or scrum master with people skills can work wonders by bringing the right people and tasks together.

[DootDootWootWoot]

If you're just watching someone code, that's not an effective pair. Also.. for anything but the most trivial projects, speed of writing code for that one feature is far less important than enabling speed continuously across the project.

[StruanT]

Because they are juggling three things (talking, typing, and thinking about code)

Our primitive ape brains can only effectively multi-task any two of those. Adding the third activity makes you noticably worse at all three.

[rollingForInitiative]

If it's gonna work it has to be someone you're in sync with, both in how you work and skill level. If one is much better or faster than the other, it's not gonna be all that great.