I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production without issue years later. We paired every day for about 11 months.
Yes, its mentally exhausting. You need to take regular breaks. You also need buy in from everyone involved, if one person is half-assing it, its going to fall apart.
The benefits I saw were many: better quality code (two sets of eyes on the code at all times, two people solving every problem or bug, always someone to ping ideas off), better understanding of the code/knowledge sharing (both of us fully understood every line of code written, why it was like that, what it was for), shipping on time (easier to make decisions to get it production ready quickly when two brains are working on it, easier to avoid bugs, boring tasks like documenting are easier too).
I don't think the project could have been completed in the time it was with only two people if we hadn't paired. There was also no disparity in experience or seniority, we were both quite equally matched.
Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
> No, one person is doing things, and another is watching and talking while the other person is doing things.
I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced.
In the piano context it's less "I'm going to explain to you what I'm playing right now" and more "What do you think of this chord, does it harmonise well with what you're doing?", "I think maybe changing it to a minor chord would help", "oh, can you show me what you mean?", "yes play the first few notes and I'll do the last one so we can see what it sounds like together". It's a back and forth to progress the whole.
Apparently, pair programming places no value on flow.
> I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced.
Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either both very junior, or it's a training scenario of some kind.
There are certainly times where flow can be difficult. However I'll offer a few other thoughts.
Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written.
I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways).
> I just don't see how it's effective
I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways:
- I am less easily distracted because I am in flow with someone else
- I am forced to consider my thoughts more carefully because I need to explain them to someone else
- I am confident that someone else can continue this work if I am unavailable
- I enjoy the camaraderie and friendships built with my pairs
- I quickly learn new tools, tricks and ideas from others
- I am able to practice my teaching or coaching skills
- I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed
- I take more breaks throughout the day
- I am able to provide and receive significantly more interpersonal feedback due to the high touch nature
- I'm likely to discover something I've missed with a different set of eyes
- I'm likely to take fewer shortcuts, or to be called up on them
- I've become a more effective verbal communicator in the rest of my life
Of course, I can also give you a list of reasons why I don't like pairing, to even it out!
However, with pretty much anything like this, just forcing it down everyone's throat is a recipe for disaster. Probably the most confusing thing about the original article was the statements "This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", followed by "It burned me out" and "I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management". Huh?
I get flow with and without pairing.
I have ADHD, so for me flow is a spectrum from "smooth, effortless, light" to "destructive hyperfocus". Pairing almost completely prevented hyperfocus in my experience.
For me, the hours zoom by like minutes. The end of the day is suddenly here, and I don't feel like I've worked at all. I was hanging out with a buddy chatting about stuff, and yet there is a pile of completed code in front of us.
https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in...
This is a very common misconception. Both of you are "working", only one of you is typing. I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. Both people are doing these things, except you're both doing them on the same task. That means that the task is often done faster, but much more importantly, its done better and the wins really rack up in the long run: you get knowledge sharing for free, you make less mistakes, better designs, write more robust software, better tests (because you have a second person to make sure they're good), have two people working on documentation etc. We ship more complex projects, with fewer errors, better documentation in less time.
> I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work.
How much of your programming is actually typing into a text editor? Maybe I'm working on different types of code as you, but for me, design/planning and problem solving is takes up about 80% of my "programming time". As I said above, not only is this faster with two brains working on it, but the results are better too.
> Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
Sure. The difference is that you're doing it all the time. Which has the benefits I mentioned above, at the cost of.. its a mentally exhausting way to work.
The project I worked on with pair programming was a large complex distributed system to deliver large amounts of data to fleets of airplanes over satellite internet (among other means), with guaranteed delivery SLA's. It took two of us 11 months from start to deployment. I've worked on simpler projects without pair programming that took longer. I don't work there anymore, but last I checked, it was still running in production without problems. I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
I spend a lot of time typing and thinking. And having to slow down and talk to another human impedes my thinking. It's much faster to just think.
> Both people are doing these things, except you're both doing them on the same task.
No, one person is doing things, and another is watching and talking while the other person is doing things.
> you get knowledge sharing for free
It's not free, it takes time to communicate, you're just doing it while trying to complete a task. The disruption to flow seems like it would be a much bigger hit than the marginal gains of trying to teach/knowledge share and work at the same time.
> How much of your programming is actually typing into a text editor?
The vast majority. It doesn't take me 80% of my time to think and plan.
> I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
I can't comment on that, but I can say that I've never worked on a project that would have benefitted from the kind of pair programming you (and OP) are describing. And it's not that I don't collaborate, but when I do, it's much shorter periods, and much longer stretches of time between. I can spend an hour planning with a peer, and then we go off and do things, and just trust that they work (and we're right the vast majority of time). We have established standards, and code reviews catch edge cases.
FWIW, I do have experience with pairing, and my experience is the same as theirs: the person not typing does a lot of design thinking. It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.
You're free to whatever interpretation you wish. I'm glad it worked out for them (and you).
> It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.
I hope you can look back at that statement and see how ludicrous it sounds.
The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.
The only time I do anything like what you're describing is in a learning context, either as teacher or student. In that case, one of us is sacrificing our time to work with the other person, but it is just that, a sacrifice, in order to serve the long term goals of the group.
And yet, my experience has been the exact opposite.
> It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting.
Fair enough. But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?
I don't have to jump out in front of a moving car to know I'll get injured if I do. I've collaborated and worked with others enough to know it's not for me. Others in places I've worked tried it, and it didn't go well, in spite of strong management desire to see it implemented. I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And in spite of the comments in the original article touting such benefits as "one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", that sounds like cognitive dissonance given the horrific problems that it caused.
And I'll assert again that I have experienced it work (in two different jobs, although one was only for a day at a time), seen it work for coworkers and a few of my peers have had it work very well too. Additionally there are other people here in this very comment section asserting that they, too, have experienced it work.
For me, it had a very real and positive impact on the projects and was a good personal experience. Your assertions to the contrary won't change that.
Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that."
At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.
I'm not saying you have to try it, just don't knock it if you haven't. I'm also not even saying that it will work for you. Maybe it really won't. But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.
Also, your car analogy is invalid. Its not at all like that. That's a bit like saying that you don't need to fly in an airplane to know they can't fly because you know other similarly heavy objects like rocks can't fly. That is, just because you know what would happen when being hit by a car without actually being hit by a car can't be applied to this very different situation.
No, it's "I have strong first hand evidence from seeing the attempts at my and other work places that pair programming is not a slam dunk improvement for software development".
> At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs.
Back at you. I'm not the only one here with strong misgivings and counter examples.
> But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others.
I stated that I don't care how others get their work done. You want to pair program? If you can maintain or exceed the expected productivity of the rest of the team, then you do you. What I strenuously object to is the heavy handed application of this "concept".
> Also, your car analogy is invalid.
Yours isn't much better. Rocks can certainly fly, if you provide enough force, but they don't do it easily and they don't do it well, and require a huge effort to make it happen. I wouldn't want to travel by flying rock.
Pairing people with the same skill set? Mostly
that’s just a waste.
1. The idea of "evenly matched" developers is a fallacy. They're never exactly equal in all areas. Each one is going to know technical things the other doesn't. One will be stronger on the back end, one on the front end, etc. One will know parts of the API the other doesn't. One is better at SQL.
2. Each will know tool/workflow tweaks the other doesn't.
3. Most importantly by far: this is how domain knowledge transfer happens. On any non-trivial codebase there are decisions and business logic baked into the code. We of course need to document these as well as possible via other means (comments, commit messages, whatever) but nothing compares to person-to-person knowledge transfer.
To be clear, full-time pairing seems rather crazy to me. My ideal (which surely isn't some folks' idea of "ideal") would be approximately several hours per week of on-demand pairing when it makes sense. In other words, a team that doesn't pair as a rule but is eager to pair when it makes sense to do so.
* Having multiple perspectives on design.
* Having an extra pair of eyes to catch things one person might miss.
* Being able to bounce ideas off each other.
* Redundancy (if you are on holiday or sick somebody else still knows the code deeply)
* Onboarding (it works better at getting me up to speed than any docs ever have)
* Motivation (i find it's kind of like having a gym buddy).
* Bonding (assuming you get along with whomever you're pairing with)
I get that not everybody likes it though.
I feel that it's somewhat irksome for introverts and companies try to use it as a means of making developers more replaceable, which some people hate.
Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from.
If the solution isn't well-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.
Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.
Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.
For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things.
1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.
Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex.
I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.