I've always done group working to some extent, especially where I need to work through an issue I've been stumped by, or where I need to bash out a consensus on a design.
Similarly, I have always had other members of the team shadow me and work together to upskill them, let them gain confidence, and get ready to work with the training wheels off when I'm not there. Many times, they catch typos and silly errors that would otherwise have been missed until later, or possibly even not caught at all. But at the same time, I expect them to be building their skills and confidence so that they can be productive on their own, and to develop their own opinions so that they can challenge designs and approaches, and come up with their own.
On many projects I have also had good experiences dividing up related work between different team members and checking back in a few times a day and comparing notes on how we're getting on, what we're finding difficult, and what we do where the related pieces of work touch each other.
These approaches are so basic and so obvious, that I'm sure most of us have been doing them since we were teenagers at school doing group projects.
But this isn't what "Pair Programming" is, or at least isn't the dogma that it has become in some organisations.
The dogmatic version of it enforces working in pairs for all, or at least most of the day, no matter the personal preferences or personality types involved. It is exhausting for introverts and allows extroverts to dominate the work. It has strict rules about who is driving and who is navigating - or, more commonly, who is spectating. Even when regularly switching driver, a dominant personality normally emerges, and does the lion's share of the thinking. This means that, while the other member(s) of the pair or mob may absorb information quickly through osmosis, it takes them longer to form opinions of their own - instead they absorb the opinion of the dominant personality. This leads to groupthink and tunnel vision. While superficial flaws and errors are picked up quickly, larger issues are more easily missed without time for quiet reflection. It is especially difficult for those with weaker verbal communications skills, but who are still strong technically.
Personally, my ego loves dogmatic Pair Programming because I am mostly an extrovert, enjoy dominating verbal conversation, and I like the attention. But enforcing it on a genuinely diverse team is bad news.
Similarly, I have always had other members of the team shadow me and work together to upskill them, let them gain confidence, and get ready to work with the training wheels off when I'm not there. Many times, they catch typos and silly errors that would otherwise have been missed until later, or possibly even not caught at all. But at the same time, I expect them to be building their skills and confidence so that they can be productive on their own, and to develop their own opinions so that they can challenge designs and approaches, and come up with their own.
On many projects I have also had good experiences dividing up related work between different team members and checking back in a few times a day and comparing notes on how we're getting on, what we're finding difficult, and what we do where the related pieces of work touch each other.
These approaches are so basic and so obvious, that I'm sure most of us have been doing them since we were teenagers at school doing group projects.
But this isn't what "Pair Programming" is, or at least isn't the dogma that it has become in some organisations.
The dogmatic version of it enforces working in pairs for all, or at least most of the day, no matter the personal preferences or personality types involved. It is exhausting for introverts and allows extroverts to dominate the work. It has strict rules about who is driving and who is navigating - or, more commonly, who is spectating. Even when regularly switching driver, a dominant personality normally emerges, and does the lion's share of the thinking. This means that, while the other member(s) of the pair or mob may absorb information quickly through osmosis, it takes them longer to form opinions of their own - instead they absorb the opinion of the dominant personality. This leads to groupthink and tunnel vision. While superficial flaws and errors are picked up quickly, larger issues are more easily missed without time for quiet reflection. It is especially difficult for those with weaker verbal communications skills, but who are still strong technically.
Personally, my ego loves dogmatic Pair Programming because I am mostly an extrovert, enjoy dominating verbal conversation, and I like the attention. But enforcing it on a genuinely diverse team is bad news.