71–80 of 180 posts
...until the pandemic hit. Now I work in a remote-first company. I have only met my team mates a couple of tines. We do all our collaboration online.
And I crave pair programming. Slack isn't good enough, code reviews are welcome but not good enough either. I enjoy pairing over Zoom to get some things done. Not every thing, but more complex tasks: I need and want the pairing.
Who would have thought?
There is of course the tradeoff that this way of working is inherently synchronous, taking away the flexibility of thinking about a problem at your own time. Developers have different cadences of coding/thinking, after all.
Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…
Even if you have a fixed meeting, you might've just started to get productive on something else, or maybe there's something that actually needs to be handled synchronously, like an incident.
It also is a lot more pleasant for neurodiverse developers. I have ADHD and pairing is not great for me. My attention doesn't work on demand, for any topic I choose. I fit chores in between engaging tasks to keep things going, creating the illusion of doing one thing after the other, but I'd rather not be interrupted or judged with either and to a neurotypical person this behavior might seem erratic and confusing.
I don’t tolerate any medication at all for any length of time, nerve pain. although it does work wonders. So I can only use non-medication techniques.
Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…
yes, this is important: for a senior / expert, knowledge transfer, i.e. showing someone else what to do, often is much slower than "just doing the work by yourself"; but that does not make its value lesser.
If you optimise for productivity today, you might regret it tomorrow.
I've been writing software since the mid nineties, and love pairing with junior devs.
I almost always learn something new too.
Pair programming definitely has pros and cons. The teams I've been on in my company have been very deliberate about when and how we pair program. Most of my experiences have been positive, especially in person pair programming. Pair programming over video calls is much harder for me.
As an introvert, I prefer to go solo unless I'm working on something I know would benefit from additional knowledge or brainpower, but I've found pairing to be the single most powerful tool I know for training junior devs and for bringing people up to speed on code bases, languages, techniques, or business domains -- which is often quite important.
There is undoubtedly a velocity cost in the short term, since ideally the junior person ("junior" here might be a senior person who is new to the code or the business) will "drive" (type) more, and some time is spent in the teaching. But the investment in higher overall knowledge of the team, and in catching bugs/avoiding dead ends early, tends to pay off.
One subtle thing that takes time and practice is deciding when to stop pairing, because one or both of you needs a break, or time to think about the problem at one's own speed.
I also think one can become over-reliant on pairing for learning. Personally I love reading (even printed books!) for learning languages, and writing for shaping thinking and capturing knowledge for future people. Not everyone loves these activities equally, but they are important skills for engineers to develop, and pairing is not a replacement for them.
Finally, sometimes it's good to just go off and think for awhile.[1]
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.