Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.
I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment:
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.
I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work.
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.
> How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours?
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 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.
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.
I’m not the person you’re responding to, but I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. It’s quite rude.
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.
I'm just going by what I've seen in my career, as well as the words that you're using to describe the process, what others in this thread are saying (on both sides of the issue), plus the countless articles I've read over the years.
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.
> 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.
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?
> 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.
> I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked.
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.
> 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."
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.
And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.
It's like arguing if a piano sounds better when played by one or two people at the same time. It's just different. Hard to argue that the solo pianist is "better".
interesting analogy. there will, of course, be things the two-player mode can produce because there's more fingers on the piano keys. I can not physically play 15-20 keys with my two hands, but two players easily could. And... it probably sounds 'better' in some regards - richer/fuller/etc. But... it's going to take a lot more practice for people to work that close together physically. There aren't, AFAIK, a lot of piano pieces written specifically for two players - but that may be more a function of my limited knowledge vs something inherent in piano music.
Except in this case, it's like one person playing while another person talks to them about what they're playing. In a purely instructional context, sure. In a performance context, it sounds crazy.
In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said:
> 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.
> In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other.
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.
> Apparently, pair programming places no value on flow.
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!
Fundamentally, if two people want to pair, and can meet their obligations as far as delivering work (produce two or more times the work than what's expected of an individual), then feel free. At the end of the day, I don't care how you do your work, any more than I'd dictate which IDE you use. The biggest concern that I'd have in a group with pair programmers is the noise from the constant talking, but most places don't care about having a quiet working environment these days.
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?
He realizes the powerful benefits of the technique, but he is an introvert and finds sustained social interaction tiring and stressful for his neurology.
> Apparently, pair programming places no value on flow.
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.
> Apparently, pair programming places no value on flow.
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.
Its important to go in with an open mind and not resist it. If you go in grudgingly thinking its not going to work and you're going to try it only to prove yourself right, then it will of course never work. I'd also read up and see how people do it rather than just having two people sit at a computer but otherwise trying to code like you usually do, otherwise you're unlikely to see any benefits.
Pairing people with the same skill set? Mostly
that’s just a waste.
Strong disagree in my experience. Even with two "evenly matched" developers:
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.
Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design.
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.
Yes. Code "is" design, unless you're working with machine code. Code is a blueprint, not the building. We sometimes tend to take high level languages for granted and forget that.
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.
That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.
Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back.
Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.
"Design" can mean a lot of different things. UI? Data structures and algorithms? API? Database schema? Whichever of these we're discussing, and whatever process we're talking about, I find it much faster to think and sketch and describe in words before writing code.
No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.
Oh, non-user facing programs is the land of well written specs, tests before implementation, design before implementation, and all the old school academic markers of good software engineering.
Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
> * Redundancy (if you are on holiday or sick somebody else still knows the code deeply)
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.
It's not about a disparity as such. I've had great pairs who I'd say are about equally "good" as me (if one must project to a 1d scale), but who have complementary skills to mine.
I think it can be good for 2 seniors when you need something right now i.e. production bug, or feature that came out of nowhere that needs to ship by EOD. Assembling a strike team of sorts.
