> You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile.

If someone's not interested in learning or growing, I don't see how pairing or not pairing makes a difference.

It is completely driven by senior developer. Many students find such pedagogy demotivating. They are not getting tasks they could solve autonomously and independently, every their step is watched as they are doing it. So, they don't even have chance to make mistake, realize mistake by themselves and then fix it. Imagine college classes done that way - everyone would rightfully complain.

Motivation and desire to learn are partly function of personality and partly function of environment.

> Imagine college classes done that way - everyone would rightfully complain.

The tutorial method is thousands of years old, actually. I suspect that if one-on-one education was economically feasible it would be the model chosen almost every time.

Having paired with people who don't know what "if" and "for" mean in a software context clear through to individuals who've been in software for longer than I've been alive, I can only say that it works more often than not.

I often hear that pairing would be terrible at this, pairing must be dreadful for that, pairing wouldn't work for the other thing. What these have in common is that they are rejections based on mental simulation of events.

But ... I've actually paired. For years. It doesn't work for everyone but it still works for most people, so long as they learn it from an experienced pair.

It is frustrating to see a thing work, over and over, then be told you must be wrong, it can't possibly work.

> It is completely driven by senior developer.

It's also driven by the company. Sometimes companies make decisions that really impact employee loyalty.

Its a colossal waste of the experienced person's time

You learn someone isn't interested in learning or growing much quicker, which itself is very important information.

Having been on the other side of this, yes, it really can be.

On the other hand, in a review-driven situation, you're back where you started, multiplied by a slow feedback cycle and competing stimuli.

Another issue with pair programming - the assumption that the benefits which are potentially produced by pairing, are often baked into estimations regarding quality of work and / or deadlines.

The current product I work on has had a team of - count em - two developers for the past year. I'm the one that is full-stack, so I get to help the less-experienced developer work on our frontend, while I have minimal time to work on the backend solo (for the most part).

My pair programmer partner, also has no interest in learning the new dev-sec-ops our company is pushing - so I get to also solo all of that work.

It's an extremely frustrating / soul-crushing scenario to be in. It's basically punishment for exhibiting competence and willingness.

It's a situation I'm hopefully out of in the next month.

Then - he randomly wants to chime in with tangentially related questions - it's basically all of the pitfalls described in the - working with a junior dev section of the OP's article - except I've tried every one of the tactics described therein, and at some point you have to question whether the junior dev really wants to be a dev or grow at all...