Reducing pair programming to numerical economic value like that is quite absurd: "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."
The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric.
I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made.
And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.
Async code reviews are slow. A code review is about getting people to agree on the code being reviewed (ideally using a set of objective guidelines). Instead of having a review done in an hour, for instance, it can easily stretch into days of back and forth to reach a consensus.
Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome.
You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems
- more context switches
- the longer code goes unmerged, the more conflicts can build up
- unmerged code can block other things
Wow... If this has been your experience then you've had rotten luck. I've never experienced this in 25 years developing professionally.
On a typical code review, a reviewer takes about 10-15 minutes tops to review the code in a PR. 75% of the time the code just gets approved. Otherwise it's usually a few minor points that are 2 minute fixes, and rarely it becomes more involved because the person was unaware of something important (so a 20-30 minute fix, or perhaps a meeting to discuss the issue and come to a concensus if nobody's really sure how to deal with it).
PR code chunks are kept small so that things are easy to review, and easy to switch back to if there's a problem. Generally there's 0-1 cycles per review. If we're working on something big, we make an integration branch for that feature and then merge the changes in multiple small PRs again, so that only the integration branch itself needs to be kept up to date with mainline. Blockages due to unmerged code are unheard of (at least I've never experienced it).
I do on average 3-4 code reviews per day, and this has been my experience for my whole career (aside from two places that did pair programming instead) spanning many companies from startups to multinationals.
The article argues in favor of "code reviews, design reviews, and general documentation" but it totally avoids discussing the merits and disadvantages of them.
It's not only pair programming that has pro and cons, and so using a different process (or more likely, a mix of different processes) always implies a tradeoff.
> While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.
It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my experience at least, laughable. It's not just about code, it's about the whole process, including other tools you might use, where and how to find things, etc. Engineers have different backgrounds that might've taught them different ways of approaching certain tasks. Some of those might stick
Sure, he's not going into extreme detail, but then again I doubt that's the point of the post. I found myself nodding in agreement as I read along, but that's probably because I've been in the trenches so long. I've done it both ways and I've never seen pair programming as having any significant advantages, but rather having drawbacks in most (though not all) situations.
Personally I love pairing -- I've learned a lot from pairing with others over the course of my career. Earlier in my career, seeing how others worked went a long way towards improving my own workflows.
I think there are some valid criticisms to be made against mandated pair programming. In some circumstances, such as thinking through a solution on the fly to a subtle bug or challenging data problem, I will usually need some alone time with the problem to come up with anything worthwhile. I'm introverted, so having someone on a screen sharing session or sitting next to me (sometimes) carries a burden that will probably reduce my creative output. But that's not always the case! Sometimes it's great having someone to point out lapses in reasoning or suggest approaches I wouldn't have thought of, or to be that person for someone else.
Anyway, I only thought to mention that because the angles given in TFA were so disappointing and also because I have seen some job ads that mention something to the effect that all programming that happens in that shop is pair-programming, and while I love pair-programming, that sounds like a special kind of hell I would love very much to avoid.
But then, I've never worked in such a shop -- maybe it's great, even if it's probably not for me?
> I'm introverted, so having someone on a screen sharing session or sitting next to me (sometimes) carries a burden that will probably reduce my creative output.
Early in my career - in a 4 person shop - I had a manager that mandated it. He was very extroverted and always talking. Pair programming was very difficult for me because my attention always shifted to him and any complex thoughts about the code would be wiped clean from my mind as he went off into some ridiculous rant. The conversations that weren't about random stuff usually went like this:
"Are you watching?"
"Yes"
"Did I make a mistake?"
"No"
"Did I make a mistake?"
"No"
"Did I make a mistake?"
"No"
"Yes I did"
"..."
He gave up after a while, thankfully. Pair programming is definitely not for me. But I'd love to work in shared IDE on different parts of the code. That seems fun - as long as there isn't a lot of talking.
this is more like what the author described as pairing than what I would hope it is like. I view the ideal (and try to make my sessions) more like translating two people working at a whiteboard to programming. It's tough to get it right though.
Personally I've turned down jobs at places which require pair programming because it drains me. There's no way I can sustain it for very long.
I'm happy to do it occasionally to transfer knowledge, but it slows me down massively because it totally changes my thought processes when I'm constantly aware of another person there with me.
I wonder how significant the effect of mandating it is on the personalities you're able to hire. Many of my by far most productive developers have been introverts like me who'd likely not to consider jobs in those kinds of environments.
how about that we're also social creatures? Devs get a bad wrap as anti-social intraverts who want to sit in a dark room alone all day, and yes there is a time for that, but I absolutely love learning from someone directly AND sharing something I know. Sometimes I wonder if the resistance to pairing is because of the weaker relationship between the individuals and not the act itself.
In the context of a job where somebody is paying you to develop software, the entire point is to produce economic value. That’s why you’re getting paid. Your entire job reduces to economic value.
There’s an argument that “teaching and learning from each other” produces more economic value in the long run, but you reach diminishing returns pretty quickly on that.
> The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric.
I don't understand your point. In a world where most developers are almost certainly gone in a couple of years, programmer velocity seems to me to be more important than getting people to understand lots of parts of the code base (once they understand 2 or 3 big chunks of it they'll be probably gone)... and to get to understand a small part of the whole it only takes a few sessions of either pair programming or, better, design sessions.
I may sound like someone who's given up on "sharing knowledge" and just cares about output... and you'd be right. Because that's the world I live in, not the world I would like to live in...
I've been in the same company for 6 years now. Got a 25% raise recently because they don't want me to leave (they were damn right I would leave soon otherwise)... in this time, I've seen many come and go... spending time teaching them more than they need to accomplish the work they need to do in the next few months is what I would call a total waste of my time... I show them what they need to see, then leave them to their own devices. Most of them are smart enough to get stuff done after just a couple of design clarifications... If I had to sit all day with them trying to explain how everything works everytime we made a change our output would go down 90% and we would be out of business in a few years.
You can pretend it’s a magical experience where all parties are teaching and learning and having a wonderful time.
In the real world it’s an inconvenience where one person invades your personal space, hovers over your shoulder on your desk with no space as you awkwardly work through who knows what and establish a pattern of dominance as one person clearly knows more than the other and will just do the work themselves while the other watches OR question every single thing typed to the bemused person at the keyboard. No personal bonds are formed during this intrusive process.
Maybe that’s the point. It’s harder to just sit at your desk and space out when you’re right next to someone else.
On the other hand I feel like pair programming sessions often get sidetracked into interesting conversations about technology or just about anything else that’s interesting, so that part is nice.
This is the biggest thing I have seen with pairing when it works. People are less likely to disrupt a pair, but they'll happily bother a single person. Enough of those happen a week, and the pair gets 20+ hours of coding vs the two singles only getting six each.
I've never experienced that. My experience was that pairing sessions were continuous, bloody hard work. My partner and I would have our noses to the grindstone throughout the session, which was strictly time-delimited (10AM to 5PM). I'd go home exhausted. Whether you're driving or navigating, you have to concentrate. The navigator has to show the driver that he's paying attention; the driver has to account for what he's doing.
Working solo, it's much easier to get sidetracked. Feeling overloaded? Well, spend a few minutes on HN.
But really, when you have trust rather than competition between colleagues it's absolutely ok to plan regular breaks and pull the emergency break when your focus juice has run out for the day. So depending on culture and how stable/jelled-in your team is pair programming shouldn't a exhaustive grind. That doesn't seem sustainable.
I've found pair programming has helped in the past when working on really complex or convoluted code.
I could sit for a day myself and maybe get my head around it, or pair program with someone else and between the two of us we get it knocked out in a few hours.
If you only have a simple code base, I think pair programming doesn't have a lot of value. But when you are in a 5million + LOC legacy app, pair programming can help a lot IME.
Most definitely. Once thing that I feel is not said about pair/mob programming, and also for Trunk Based Development for that matter, is that they essentially require a different mindset and ways to approach/solve a problem.
If you're going to develop a feature in pair-programming in the exact same way you would if you'd be doing it alone, yes, it might not be the most effective thing.
If both/many programmers discuss the ideia first, implement it, correct it on the fly, and when it's done it's completely done, with no waiting time, no delaying the value, no miscommunication in comment boxes, then it's highly effective.
I'm pair programming ambivalent. A lot folks like it. I mostly don't, but I enjoy collaborating more broadly, and sometimes a pairing session can be truly invaluable when the task at hand is right. I think it has many benefits in that at least knowledge isn't entirely siloed with 1 contributor. It's not the silver bullet to solving wider system awareness problems though.
>> Not to mention the coveted flow state that most developers look for.
That is perhaps the single biggest factor around why I prefer not to pair for the most part. Frankly I just can't think as well about creative, problem solving stuff when I'm pairing.
There's also an "enjoyability" issue.
If people enjoy pair programming, and this will vary by individual, they'll find ways to keep practicing it even if it's not the most efficient option (and actually there's a good case it is long term cost effective).
If people do not enjoy pair programming, they'll find ways to avoid practicing it even if has many economic or systemic benefits.
As we often find, it's a people thing: we remain emotion-driven and reward-driven beings and that isn't going to change any time soon.
Yeah, personally I don't particularly like it, because I don't particularly like talking about the coding I'm doing - I like just being in it. But I can totally see that it's very effective and enjoyable for a lot of people.
I really enjoy a pairing or mobbing session, but I haven’t figured out a good way to integrate a key part of my process.
I usually attempt an aggressive reshaping commit history as I find it allows me to re-evaluate and improve the code, but it also allows me to craft a PR that can be understood commit by commit (and even split out unrelated work to prevent big PRs).
I appreciate reviewing small PRs that tell a story (and revisiting a nice PR years later for context), so I put a lot of effort into it.
Often it’s an exercise in tedium that doesn’t really suit 10-15 min handoffs when you’re stuck deep in a rebase and it gets tougher when the commits are all “WIP,” but the biggest thing that bothers me is that doing so often clobbers the other devs contribution if the commits have been sufficiently remixed, and I want their contributions recognized in the history.
Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, losing confidence, taking shortcuts to try to keep up and making a mess, you have two programmers in a state of flow producing high-quality work.
As a side-effect, you also get great shared knowledge of the code base.
Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Myself I actually enjoy this quite a bit. For avoiding and catching mistakes is useful but not a guarantee at all especially as their way of thinking is synchronised. There are other techniques for these as well (tools, patterns, reviews, ...) allowing two people working with two things.
Shared knowledge of a codebase is pretty useful. While it lasts. Also pitty it involves exactly 2 persons only. Documentation is far more reliable way of sharing code knowledge, especially long term and in changing team composition.
> Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation.
Feels like a reductionist statement. When working on a large codebase (call it legacy even, as everything devolves into legacy code given enough years), it's impossible to keep all the details in your head. Code review can provide the additional context missing to the developer implementing a task, but I'm sure you've been in the same situation before; where a feature change, even small in scope would crisscross multiple files, and without testing it out you're unable to review conformance.
As an example. When I was team lead on a large and legacy SaaS project in the past, I pretty often would pair with other developers on the team, and their input as well as my input had us catch situations that while developing in isolation we could have missed. Even in a standard code review. Because during development we were deeply entrenched in the code and able to often try out multiple approaches for a problem.
It definitely does not work that way for me. No matter which role I am, a lot more effort goes into following what other person does then when I do it by myself. This is like saying that two people hugging while each is using just one leg are faster, because they have to focus only on one leg while walking.
>“I don’t know why more people don’t do it,” Sanjay said, of programming with a partner.
>“You need to find someone that you’re gonna pair-program with who’s compatible with your way of thinking, so that the two of you together are a complementary force,” Jeff said. [...]
They aren't "just" pair reprogramming -- they are practically married. They pair only with each other, forever, and they are best friends. It's not an arbitrary or rotating matchup.
Having shared _exactly_ this kind of working relationship with several co-workers over the years, most of whom work at Google now, I'd argue that the problem comes down to counting things that don't count and the difficulty in counting things that actually do count, like execution, flow, shared mental model, vision, and ideation. There is a rhythm that arises from pairs work that I find much more peaceful than my own type-furiously-and-swear-vigorously personal style.
I can work alone effectively being an introvert, but there is no question that the results and impact improve with a pair of talented co-workers who are mutually inclined toward pairs work. I don't think it has to be every time for everything, but when there is consensus on the approach, I see no reason to disallow it because some of the greatest achievements in science have come through this kind of collaboration. If it doesn't work for you, there's no reason to make individual, pairs, or mob programming the only way of working. It's a spectrum of work styles and that's OK.
>>> 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.
Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.
In my experience, pair programming is really fun and helpful for some parts of my work, for example brainstorming solution ideas or finding bugs.
> Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.
That's assuming two people pair programming would otherwise need to communicate about every individual line of code.
No, they would need to communicate about the ideas and thought processes behind every individual line of code. If not now, then the next time there's a bug in said lines.
> ideas and thought processes behind every individual line of code
I realize you're being hyperbolic (at least as hyperbolic as the parent), but this is one of the big hangups of pair programming for me: waiting for folks to get through boilerplate. Let's talk ideas and thought processes about the important (or at a minimum non-boilerplate bits of) code, not an entire programming session.
"Alex, what were your thought processes that lead you to use 'i' for a loop variable?"
"Alex, what were your thought processes that lead you to a for loop here, rather than a {while loop/list comprehension/map operation/linq expression}?"
> Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.
I actually disagree pretty strongly with this.
If you have two programmers working on the same project at the same time, you can split up the project along a pre-negotiated interface ahead of time. It takes some amount of communication to do that, but you don’t have to communicate about every single line of code the way you do with pair programming. In fact I’d say my #1 problem with pair programming is the added communication overhead.
I consider that brainstorming and working with a team mate, not pair programming. As a daily thing it's ridiculous and only for people who are exceptionally friendly and need a lot of human interaction. Give me a problem, a laptop, and some space and I'm all set. I agree with brainstorming during the design phase(s) of a project though, lots of good ideas come out and there is some synergy you can have that will never happen over zoom or email.
>The output of pair programming must be greater than 2x the output of a single programmer to make sense.
IME it does. Most of coding is identifying problems and two sets of eyes lets you hone in on the problems quicker.
With design, two sets of eyes spots things that you will otherwise miss.
Programming isnt chopping wood. If you're experience with it is that you're bashing out code like you're on a factory production line then something has gone wrong.
>While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.
I've never seen this happen once. If somebody managed to write docs that correctly anticipated every potential question I'd be very surprised.
IMHO, pair programming is a useful thing, but not for the reasons it's usually sold on.
It is a really good oboarding vehicle. Pair an Experienced Dev and a new hire, and let the former guide the latter through the codebase. It also works great for implementing changes involving very complex parts of the codebase, usually the kind that interact with many different subsystems, which can get really tricky toget a good grasp on.
Pair programming can be powerful with the right people and the right problem. It's a situational tool that can speed up progress in certain cases. Sometimes diving deeply into code is scary and having someone else right there can provide a feeling of safety that's conducive to making real progress. Also, sometimes programmers can have complimentary skills that can help them solve hard problems together on the spot. Pair programming sessions with the right people can also be intensely productive - people sometimes perform at a higher level when they're being watched. I've had very productive 3 hour coding sessions with team mates.
What I don't like is weekly or recurring pair programming sessions. That's always a bad idea. Pair programming is a powerful tool but should be used judiciously and situationally.
20 years ago I worked for Adobe on the Acrobat team. They brought me in because they needed some Windows expertise to help a team of talented developers who had mostly coded on the Mac.
I don't think the term "pair programming" had been invented yet - at least I'd never heard of it - but when I was in the office I often spent a few hours a day on "house calls". People would ping me and I made the rounds advising them on Windows issues.
It was focused time. No one needed my help much of the time, but when they did, we could work through a problem quickly and they would be better equipped to handle it on their own in the future. They always "drove", I just watched and discussed and helped troubleshoot.
It was really great. As you said, what made it work was that I was there when someone asked for my assistance, not just because "pair programming" was the thing to do.
I had a role as a mentor/go-to-guy for a complicated codebase and had a similar experience. I really enjoyed helping people out and loved the positive interaction, I would never have called it pair-programming and funnily enough we did have some kind of pair programming initiative at the time.
If I were to give any advice to dev leads/teams/management that wants to introduce pair programming, it's good to put people of differing capabilities and expertise together. That way there's some value being added, and you're spreading around the arcane knowledge of your platform.
In general I agree. I've found pair programming to be immensely beneficial and productive for some cases.
I wouldn't go so far as to say recurring sessions are always bad, but I do think that not all tasks benefit from having a pair work on it.
When I have been very attuned with my teammates in terms of the system we were building and how we were building then pairing sessions became much less valuable on work that was very low novelty and was some iteration of a well-established pattern.
One of the things I believe the author is missing is flow efficiency vs resource efficiency. To reduce handoff and waste, sometimes the utilisation of a single resource may go down.
Pairing with rotation results in a situation where everyone on the team is familiar with all the parts of the system. Apart from the bus problem, which is rather low-risk, it means that you don't have to wait for the expert in subsystem X to have finished what he's doing and move to the new task; everyone's a subsystem X expert.
I don't think it's always worth pairing. Easy work that doesn't need expertise is best done solo.
I acknowledge the "velocity" accusation; I've never seen a pair work faster than two skilled solo developers. But the quality of the output from a pair is generally a lot higher than that from a solo coder. It really does help to have someone looking over your shoulder. I've not seen a comparison of solo and pair velocity that takes into account code quality, and debugging and bug-fixing effort.
I've only used it once in my career, and at the time I was 'junior' to the other dev with the tools being used on a particular project (I was more senior/experienced than him overall though and had more produce expertise).
Did it for a long week (about 80 hours actually) when we were under a very tight timeline to get a product out the door - I actually thought it was extremely effective and productive - gained months worth of learning in a very short timeframe.
On the other hand, no way would I want to work someplace where it was assumed you would pair with someone all day every day.
It depends on the people. Dean and Ghemawat at Google are so used to coding together that Wired wrote about them as if they are one person (hence hyphenated double name in the title): https://www.wired.com/dean-and-ghemawat/
I can see where the author is coming from, but I have also had a few good pair programming sessions.
Pair programming where one is more of a mentee instead of a reviewer should be useful to upskill the mentee so the pair are at more similar levels.
Indeed. In fact, following OP's logic gets absurd really fast : "Dean and Ghemawat would have been twice as productive if they'd worked each on their own! What a waste for the world !"
Sounds like an exception, not the rule. At least, I've never seen two people who coded together all the time. Not in the 20 years I've been a software developer (in both startups and in BigCorpInc).
I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two.
We then spent every day of the next 2 weeks on near 8 hour videocalls developing some remaining features on his plate.
It was an extremely effective knowledge transfer process. I learned plenty about this bizarre program and it's nonsensical logic, able to figure out future problems, and ended up as one of the main bits of glue keeping it all from collapsing.
I also found it very rewarding to work that closely with a more senior developer, got a bunch of more general advice, had some interesting tangential discussions, and made a friend. Also got plenty of advice to leave the shitty company and it's terrible software asap.
I dunno if I'd want pair programming day to day, but it was a great experience at the time, and made my entry to the role much smoother than anyone elses.
The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it.
Yeah I could never be on a video call for that long. There is a subprocess in my brain that starts running at 95% when I'm on a video call, like a kind of performance anxiety. I can deal with longer voice calls, but I can't really work during a call so it's only useful for syncing up. A call longer than an hour has probably become inefficient in some dimension.
Pair programming is quite intensive when done correctly. You build stamina with time. But even so, using the Pomodoro technique is the way forward. Someone driving for 20/25 minutes, then 5/10 rest, and switch the driver.
Even so, I will still not do it 8 hours a day. Probably 6, to give you time to do other stuff, like investigations, admin, ...
At one time in my career I pair programmed pretty much all day, every day for the better part of four years, with the same person. We started with an existing codebase, but even from the start most of the work we did was on new features.
It is intense, but--at least in my experience--it was also very productive. You basically can't/don't ever slack off. And I learned a lot from the other developer (mainly about various tools). Things that theoretically I could have learned on my own but in practice I probably never would have.
If I had it to do over again I would definitely choose to do it again.
Transferring arcane project knowledge is the best use case of pair programming I think. That and bugsquashing a complex codebase. I could never imagine developing features with pair programming, but the prior two situations really do benefit from a bit of a mind melding.
>The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it.
Sounds like a real professional, you lucked out. The standard case is to just inherit that garbage and pray to god nothing breaks when you touch it.
They figured it out on their own in a month or two. You figured it out with 2 other developers in a few weeks. Meanwhile, those developers did not make progress on their tasks. This seems to only be an advantage for you as the newcomer to get ramped up quicker.
Another potential disadvantage is that you may have been influenced by their methods and not having looked at the code independently, your own insight and input may have be limited.
It was just me and the more experienced guy, and we finished what he was working on. The other guy was busy with other things, and never had a similar induction of his own. When I started to work with him after those 2 weeks, it was very apparent that I had caught up, and likely surpassed his ability with the system.
And given the highly unintuitive nature of that system and the rushed training, there was plenty of room left for insight and input without requiring the same initial period of confusion and frustration that caused him and the other devs to have such a negative and lasting view of the system.
And more generally, I'm not sure why you feel the need to poke holes and find potential negatives in what was a positive training experience. Especially when what you've said could apply to any kind of training, and disregards the situation as described.
This sentence can be (and has been in the comments) criticized from many angles:
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.
I think it's bad because it shows a lack of understanding of metrics: The only valid productivity metric is code that works, and that everyone agrees does what it is meant to do. Code that does what it is meant to do without bugs is worth a lot more. Try quantifying that. I dare you.
Counterbalancing that is time-to-market. Expedient hacks are worth a lot, too. That you can, sort of, quantify. Risk capital costs a lot more than cash flow. Do your coders understand that?
Where to use pair programming? Probably not when you are racing to find product market fit. Possibly yes when you can lose existing customers due to a nasty bug (that may have root causes in early stage expedience).
Penn and Teller develop their tricks together. Two-seater attack aircraft are a thing. Rally drivers have a driver and a navigator. Apprentices are taught in part through pairing.
> Like standups and pointing, it feels like a patronizing exercise we only force on devs.
There's truth in that. On one hand, many of our practices is formalised problem solving under the (non-)constraints of software. Others are cargo culted, clueless, patronising and painful.
I think the difference is that the other activities you mentioned were execution/performance, while software development is a combination of engineering and creativity.
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 "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.
> Pair programmers tend to give feedback that's more appropriate in a design or code review.
What's his evidence? Why is it more appropriate there (after the code is written) than here (before/during)?
> For the pairs that follow this, the only feedback that's left tends to be bikeshedding or stylistic, both of which kill velocity.
That's, um, bullshit. Pair programming can pick up mistakes before they propagate, which increases velocity.
> It's like having a backseat driver.
I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.
> Alternatives like code reviews, design reviews, and general documentation are much better 1-to-n ways to share knowledge instead of 1-to-1.
Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.
> In addition, most of these alternatives be done asynchronously.
> I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.
I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.
I don't think that is good analogy. Driving race with driver and navigator are in completely different then anything related to programming or even pair programming.
That analogy is just yet another way how to shut up people who dont like the process.
The way some people pair is really more similar to rally driving than you give it credit. I hate backseat driver style pair programming. Strong-style is very different and more like right-seat (I’m in the US, so let’s say not-driver seat) driving. https://llewellynfalco.blogspot.com/2014/06/llewellyns-stron...
> In that case explaining why you like anything is a way to shut people up who don't
No. It is just that specifically agile has a way to responding to people who dont like something with very very handwavy explanations that feel good, but dont really mean anything. Explaining why you personally like something is entirely different kind of communication. Explaining why you think something works well is also different. But, going into "this makes sense, because two people make sense in rally racing" is neither of those.
Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
> Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
Perhaps unintentionally, a good analogy for traditional software teams. Eleven players, one or two stars, the other players mostly looking good because they can pass the ball to the top players.
In the end, all analogies suck. Pair programming is a pretty unique situation in the workplace, it works great for some people, others will never like it. It worked for me because I was kept on task. It may have slowed down the top performer but that person appreciated the company. Overall I think it made our team of 8 at the time more productive than they’d have been with separate assignments, and it really helped with team cohesion.
> Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
There seems to be two directions of analogies here. One is arguing from subject to analog. “Programming is like rally car driving so we should act like they do.” Pretty crummy argument. I’d have no answer to your “why rally car?” question.
The other direction is explaining from subject to analog. “Strong-style pair programming is like rally car driving.” There’s much less of a claim here. I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding. So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about (not that it’s the most similar context).
In the latter case, the claim of fitness is separate from the analogy. “This method is useful. It’s like one rally car drivers use”. There’s no “because” in there.
> I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding.So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about
It is fair to guess that nearly no one here ever sat in rally car. We know it has navigátor, but we don't actually know what navigator exactly does. And I genuinely don't see many similarities. It seem to be more about split second decision making in situation where you need to speed up or slow down toward turn.
You don’t need to have sat in a rally car. The split second decision making is the context, not the method. The context doesn’t have to match perfectly. They just share the attribute of “high cognitive load”.
Did you read the link I posted? The essence of the idea is you have one person who takes physical action, makes small decisions and take orders. That person is called “driver”. You have another person who makes larger decisions and gives orders. That person is called “navigator”.
The dynamic I just described is true of rally car driving and strong style pair programming. It’s not true for most pair programming or most other types of driving.
> Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.
I think PR reviews can be a resource for other engineers on the team to learn from beyond just the PR author. Granted, I think pair programming can probably deliver these lessons more effectively since you can have a live conversation about it and clear up any confusion there.
>> In addition, most of these alternatives be done asynchronously.
> And this is better, because...?
I don’t know the author’s feelings here, but I think this makes some sense in the context of the rising popularity of remote work. It isn’t necessarily a given that you’re in a similar time zone to your teammates.
I’ve also been interested in the topic of async work throughout the pandemic, with companies like Gitlab and Doist as examples who also evangelize the practice. I’ve pushed for some of those async practices on my team at work but feel like we’ve had mixed to little success with them.
So I agree with your skepticism of “async is better”, even if there was some reasoning provided.
Yeah it would be weird to me if programming is some unique task where two people solving a complex problem together is a bad thing.
I'd not done it much in the past but recently seen it done more and participated more - each time it's been useful. I paired to deploy some work, and having both of us work together was really helpful as we could talk through issues we were seeing as we went and it taught me more about infra & them more about the project.
What's weird and unique about work that one person can do better than two? Novel writing is complex, chess is complex, art is complex. Individuals do these things all the time.
Chess seems like an odd addition there, would two people who are able to discuss strategy and reason about the next move be worse than one? For writing, workshopping jokes or scenes happens a lot doesn't it? Particularly with scripts.
When it comes to novels and art though, there's a focus on producing one persons imagined work, edited and helped by others. When it comes to programming, particularly in a company, there's a problem to solve.
Is it common in other fields of engineering to say that only one engineer can work on a problem at once?
> Individuals do these things all the time.
Individuals code alone all the time too. What I'm commenting on is the idea that programming together with someone is terrible.
> Novel writing is complex, chess is complex, art is complex.
Well one thing you need to consider is that most software is not written in small, artisian batches but at scale. Pairing is one way to promote doing development and all the things you mention at a greater capacity than the individual.
Asynchronous workflows should be the default. Interruptions are almost universally bad, so being able to fit a code review into your work day whenever you want is much better.
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 also have ADHD and find pair programming is great for me. Having a person that I am working directly with helps me keep on task and prevents my brain wandering off to do other things or scattering around a bunch of tasks.
Sometimes it helps me to have an external force help direct my focus.
I've completely blanked out more than once on pair programming where my attention went into what I like to call "brute force mode", where your working memory scatters every few seconds or so, and you keep starting thoughts from scratch.
It honestly feels like torture to me.
Switching tasks lets me reset from this state well enough, so I consider it essential coping.
But you're breaking someone else's productive time. The way around this is (1) having enough work prepared that you can start on something else and (2) cutting your PRs well enough for them to be entire (sub-)tasks. And if you can't, maybe you need to cut smaller tasks.
> In "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.
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.
Just to tag along (I was going to quote and write just about all the same things), but with two developers, the HUGE value-add is codebase knowledge.
If two people on a team regularly contribute to a repo, one person likes to work on feature A, and the other feature B, and all of a sudden, the feature B person leaves and never comes back, that will kill velocity. Even if feature A person has been doing code reviews, a code review is much different than being aware of the system and continuing to improve a feature. Now person A has to either read documentation (which is, for the sake of code writing, a 0 velocity), or take larger tours through the code to figure out why a feature is how it is, and what needs to be done.
So the big question for anyone is if they want to focus on velocity/lines per day, or consistently smooth development. You can get both of those things when everyone is doing their own tickets, but that will immediately stop as soon as there is a change in your team.
I don't think pairing is perfect, or mobbing for that matter, but it does give clients a more consistent/smooth experience if they are okay with paying more for quality than speed. It does take the right kind of people and the right kind of project, just like any problem and tool set.
I'll tag along as well. (But I happen to think pair programming is a beautiful thing.)
Code reviews in real time, in situ.
"White board discussions" in real time, in situ.
Learning how someone else codes/debugs.
These are all worth the price of pairing up engineers in my mind.
If we're talking agile development, I would love it if all engineers could get paired up for at least one sprint a year. Especially less experienced or new to the team engineers. I suspect it will be the pairing experiences that foster the most professional growth.
Oh, I should have mentioned, I mob program every day at my current job, and pair programmed every day at my previous job, and both were very successful and enjoyable jobs.
One more, though this is hard to explain analytically: shared language about and mental model of the codebase. If four people build a platform working separately, they will each come out of the project with subtly different ideas of what the platform is and how it's organized.
That's kind of subjective and I don't think I could prove its usefulness on graph paper to someone who isn't convinced, but I think it's real and significant. (and hence I'm curious if people who have mobbed a lot agree)
I have this exact issue. My client has a few teams working on related products on different platforms and languages, and when we discuss bugs, I'll use a term that will almost immediately get a "oh, that's not what you mean, because thing x in this context means thing y." For example, iOS sandbox applications vs testflight applications vs sandbox purchases. Both applications use sandbox purchases, so just saying "sandbox" is ambiguous or can often cause confusion.
My biggest gripe with pair programming is that people are already too close to me when they're at their own desk minding their own business. I love working on closely related or even intertwined projects, however. It'd be interesting to work on a really good pair team for a little bit, see what a "perfect example" looks like.
I also find that pair programming can be a great way to train programmers in areas of knowledge they may not be up to speed on, to mentor junior programmers, or to just learn from your peers as they approach problems from different perspectives.
i also find paring to be useful when troubleshooting or working on a hard to find bug.
pairing shouldn't be the norm, but it can certainly be useful.
Well, yes, pair programming comes with a builtin permanent reduction on individual productivity. Partial knowledge comes with a builtin sporadic reduction on individual productivity when there are personal changes.
What is higher depends on a lot of details. You will see a lot of completely different experiences, all real, none alike.
> In "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.
> Pair programming can pick up mistakes before they propagate, which increases velocity.
Notice how it's "reduce bugs" twice with some other hand-waving qualities thrown in. Even if you have some solo developer write code with a bug, having another developer go through and fix it is a time saver over PP for all the code that was not error prone. Then we have the metric mixing issue of measuring developer code quality, over time, when mixing more than 1 person in a task.
> And this is better, because...?
Because you can avoid paying for idle time. The most common quality of pair programming team (considered productive or not) is watching one member waiting to see the other write out the function and functionality that was already agreed upon. Developers already do this when they have a tough problem. They invite others to talk and look through the code, ad hoc.
Pair programming has already been tried by a multitude of teams across decades and it does not produce results that have driven it's widespread adoption. End of story.
Well said. I would add to that: pair programming is a unique opportunity to create human connections between teammates, which is very valuable in general, and even more valuable in a remote setup.
Pair programming is exhausting and definitely not for everybody and for every single day.
But.
This is still the best way to exchange knowledge and produce code when normally you would need a code review.
Pair programming is not a waste of time. It does not cost twice as much -- it actually costs less.
It costs less because having another person working with you cuts all the procrastination and keeps things in focus.
It costs less because now you have to discuss every part of the design with another person which is likely going to lead to better design.
It costs less because if one person doesn't know it or spot it, the other person will.
It costs less because you get immediate knowledge transfer and two people who can continue the project. Things can continue moving forward even if one person gets sick or leave the project.
It costs less because people learn new stuff crazy fast when they can observe other person doing things they don't know.
It costs less because actual people (like me) like to work with other people. It is fun.
It costs less because code review is a shitty process where 99% of people fake they made a review and only pick on stuff that immediately stands out rather than actually trying to thoroughly understand and analyse the change.
Unless you have a brilliant developer that can do everything by his/her own with no help or review. Consider yourself lucky.
Pair programming is a social event and should be employed when you want to have fun with your coworkers while doing work. As such pair programming is amazing. Sure you might write worse code and give/receive worse feedback but that is not the point. If you have fun with your coworkers while doing work, I would call that a net benefit.
179 comments
[ 0.26 ms ] story [ 206 ms ] threadThe point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric.
Utterly ridiculous. I despair sometimes.
And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.
Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome.
You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things
On a typical code review, a reviewer takes about 10-15 minutes tops to review the code in a PR. 75% of the time the code just gets approved. Otherwise it's usually a few minor points that are 2 minute fixes, and rarely it becomes more involved because the person was unaware of something important (so a 20-30 minute fix, or perhaps a meeting to discuss the issue and come to a concensus if nobody's really sure how to deal with it).
PR code chunks are kept small so that things are easy to review, and easy to switch back to if there's a problem. Generally there's 0-1 cycles per review. If we're working on something big, we make an integration branch for that feature and then merge the changes in multiple small PRs again, so that only the integration branch itself needs to be kept up to date with mainline. Blockages due to unmerged code are unheard of (at least I've never experienced it).
I do on average 3-4 code reviews per day, and this has been my experience for my whole career (aside from two places that did pair programming instead) spanning many companies from startups to multinationals.
The article argues in favor of "code reviews, design reviews, and general documentation" but it totally avoids discussing the merits and disadvantages of them.
It's not only pair programming that has pro and cons, and so using a different process (or more likely, a mix of different processes) always implies a tradeoff.
> While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.
It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my experience at least, laughable. It's not just about code, it's about the whole process, including other tools you might use, where and how to find things, etc. Engineers have different backgrounds that might've taught them different ways of approaching certain tasks. Some of those might stick
Personally I love pairing -- I've learned a lot from pairing with others over the course of my career. Earlier in my career, seeing how others worked went a long way towards improving my own workflows.
I think there are some valid criticisms to be made against mandated pair programming. In some circumstances, such as thinking through a solution on the fly to a subtle bug or challenging data problem, I will usually need some alone time with the problem to come up with anything worthwhile. I'm introverted, so having someone on a screen sharing session or sitting next to me (sometimes) carries a burden that will probably reduce my creative output. But that's not always the case! Sometimes it's great having someone to point out lapses in reasoning or suggest approaches I wouldn't have thought of, or to be that person for someone else.
Anyway, I only thought to mention that because the angles given in TFA were so disappointing and also because I have seen some job ads that mention something to the effect that all programming that happens in that shop is pair-programming, and while I love pair-programming, that sounds like a special kind of hell I would love very much to avoid.
But then, I've never worked in such a shop -- maybe it's great, even if it's probably not for me?
Early in my career - in a 4 person shop - I had a manager that mandated it. He was very extroverted and always talking. Pair programming was very difficult for me because my attention always shifted to him and any complex thoughts about the code would be wiped clean from my mind as he went off into some ridiculous rant. The conversations that weren't about random stuff usually went like this:
"Are you watching?" "Yes" "Did I make a mistake?" "No" "Did I make a mistake?" "No" "Did I make a mistake?" "No" "Yes I did" "..."
He gave up after a while, thankfully. Pair programming is definitely not for me. But I'd love to work in shared IDE on different parts of the code. That seems fun - as long as there isn't a lot of talking.
I'm happy to do it occasionally to transfer knowledge, but it slows me down massively because it totally changes my thought processes when I'm constantly aware of another person there with me.
I wonder how significant the effect of mandating it is on the personalities you're able to hire. Many of my by far most productive developers have been introverts like me who'd likely not to consider jobs in those kinds of environments.
There’s an argument that “teaching and learning from each other” produces more economic value in the long run, but you reach diminishing returns pretty quickly on that.
I don't understand your point. In a world where most developers are almost certainly gone in a couple of years, programmer velocity seems to me to be more important than getting people to understand lots of parts of the code base (once they understand 2 or 3 big chunks of it they'll be probably gone)... and to get to understand a small part of the whole it only takes a few sessions of either pair programming or, better, design sessions.
I may sound like someone who's given up on "sharing knowledge" and just cares about output... and you'd be right. Because that's the world I live in, not the world I would like to live in...
I've been in the same company for 6 years now. Got a 25% raise recently because they don't want me to leave (they were damn right I would leave soon otherwise)... in this time, I've seen many come and go... spending time teaching them more than they need to accomplish the work they need to do in the next few months is what I would call a total waste of my time... I show them what they need to see, then leave them to their own devices. Most of them are smart enough to get stuff done after just a couple of design clarifications... If I had to sit all day with them trying to explain how everything works everytime we made a change our output would go down 90% and we would be out of business in a few years.
You can pretend it’s a magical experience where all parties are teaching and learning and having a wonderful time.
In the real world it’s an inconvenience where one person invades your personal space, hovers over your shoulder on your desk with no space as you awkwardly work through who knows what and establish a pattern of dominance as one person clearly knows more than the other and will just do the work themselves while the other watches OR question every single thing typed to the bemused person at the keyboard. No personal bonds are formed during this intrusive process.
On the other hand I feel like pair programming sessions often get sidetracked into interesting conversations about technology or just about anything else that’s interesting, so that part is nice.
I've never experienced that. My experience was that pairing sessions were continuous, bloody hard work. My partner and I would have our noses to the grindstone throughout the session, which was strictly time-delimited (10AM to 5PM). I'd go home exhausted. Whether you're driving or navigating, you have to concentrate. The navigator has to show the driver that he's paying attention; the driver has to account for what he's doing.
Working solo, it's much easier to get sidetracked. Feeling overloaded? Well, spend a few minutes on HN.
But really, when you have trust rather than competition between colleagues it's absolutely ok to plan regular breaks and pull the emergency break when your focus juice has run out for the day. So depending on culture and how stable/jelled-in your team is pair programming shouldn't a exhaustive grind. That doesn't seem sustainable.
I could sit for a day myself and maybe get my head around it, or pair program with someone else and between the two of us we get it knocked out in a few hours.
If you only have a simple code base, I think pair programming doesn't have a lot of value. But when you are in a 5million + LOC legacy app, pair programming can help a lot IME.
If you're going to develop a feature in pair-programming in the exact same way you would if you'd be doing it alone, yes, it might not be the most effective thing.
If both/many programmers discuss the ideia first, implement it, correct it on the fly, and when it's done it's completely done, with no waiting time, no delaying the value, no miscommunication in comment boxes, then it's highly effective.
It all comes down to measuring outcomes over time. Doing agile is doing right-ish things at the right-ish times, including ways of working.
Use retros - are we being efficient over time? Why and when? Why not and when not?
My teams tend to flow in and out of pairs, mobs and single contributions, all depending on task at hand and circumstance.
Flow! Are you flowing? How do you know?
Over time I’ve noticed that really well gelled pair and/or mobs deliver more consistently, over longer periods of time. YMMV.
>> Not to mention the coveted flow state that most developers look for.
That is perhaps the single biggest factor around why I prefer not to pair for the most part. Frankly I just can't think as well about creative, problem solving stuff when I'm pairing.
There's also an "enjoyability" issue.
If people enjoy pair programming, and this will vary by individual, they'll find ways to keep practicing it even if it's not the most efficient option (and actually there's a good case it is long term cost effective).
If people do not enjoy pair programming, they'll find ways to avoid practicing it even if has many economic or systemic benefits.
As we often find, it's a people thing: we remain emotion-driven and reward-driven beings and that isn't going to change any time soon.
I usually attempt an aggressive reshaping commit history as I find it allows me to re-evaluate and improve the code, but it also allows me to craft a PR that can be understood commit by commit (and even split out unrelated work to prevent big PRs).
I appreciate reviewing small PRs that tell a story (and revisiting a nice PR years later for context), so I put a lot of effort into it.
Often it’s an exercise in tedium that doesn’t really suit 10-15 min handoffs when you’re stuck deep in a rebase and it gets tougher when the commits are all “WIP,” but the biggest thing that bothers me is that doing so often clobbers the other devs contribution if the commits have been sufficiently remixed, and I want their contributions recognized in the history.
As a side-effect, you also get great shared knowledge of the code base.
Shared knowledge of a codebase is pretty useful. While it lasts. Also pitty it involves exactly 2 persons only. Documentation is far more reliable way of sharing code knowledge, especially long term and in changing team composition.
Feels like a reductionist statement. When working on a large codebase (call it legacy even, as everything devolves into legacy code given enough years), it's impossible to keep all the details in your head. Code review can provide the additional context missing to the developer implementing a task, but I'm sure you've been in the same situation before; where a feature change, even small in scope would crisscross multiple files, and without testing it out you're unable to review conformance.
As an example. When I was team lead on a large and legacy SaaS project in the past, I pretty often would pair with other developers on the team, and their input as well as my input had us catch situations that while developing in isolation we could have missed. Even in a standard code review. Because during development we were deeply entrenched in the code and able to often try out multiple approaches for a problem.
>“I don’t know why more people don’t do it,” Sanjay said, of programming with a partner.
>“You need to find someone that you’re gonna pair-program with who’s compatible with your way of thinking, so that the two of you together are a complementary force,” Jeff said. [...]
I can work alone effectively being an introvert, but there is no question that the results and impact improve with a pair of talented co-workers who are mutually inclined toward pairs work. I don't think it has to be every time for everything, but when there is consensus on the approach, I see no reason to disallow it because some of the greatest achievements in science have come through this kind of collaboration. If it doesn't work for you, there's no reason to make individual, pairs, or mob programming the only way of working. It's a spectrum of work styles and that's OK.
Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.
In my experience, pair programming is really fun and helpful for some parts of my work, for example brainstorming solution ideas or finding bugs.
That's assuming two people pair programming would otherwise need to communicate about every individual line of code.
I realize you're being hyperbolic (at least as hyperbolic as the parent), but this is one of the big hangups of pair programming for me: waiting for folks to get through boilerplate. Let's talk ideas and thought processes about the important (or at a minimum non-boilerplate bits of) code, not an entire programming session.
"Alex, what were your thought processes that lead you to use 'i' for a loop variable?"
I actually disagree pretty strongly with this.
If you have two programmers working on the same project at the same time, you can split up the project along a pre-negotiated interface ahead of time. It takes some amount of communication to do that, but you don’t have to communicate about every single line of code the way you do with pair programming. In fact I’d say my #1 problem with pair programming is the added communication overhead.
IME it does. Most of coding is identifying problems and two sets of eyes lets you hone in on the problems quicker.
With design, two sets of eyes spots things that you will otherwise miss.
Programming isnt chopping wood. If you're experience with it is that you're bashing out code like you're on a factory production line then something has gone wrong.
>While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.
I've never seen this happen once. If somebody managed to write docs that correctly anticipated every potential question I'd be very surprised.
Me neither.
When you need pairing, it's super powerful and cannot be replaced. When you don't need it, don't do it.
It is a really good oboarding vehicle. Pair an Experienced Dev and a new hire, and let the former guide the latter through the codebase. It also works great for implementing changes involving very complex parts of the codebase, usually the kind that interact with many different subsystems, which can get really tricky toget a good grasp on.
Not exactly a great attitude, but it’s how I came across the post.
What I don't like is weekly or recurring pair programming sessions. That's always a bad idea. Pair programming is a powerful tool but should be used judiciously and situationally.
I don't think the term "pair programming" had been invented yet - at least I'd never heard of it - but when I was in the office I often spent a few hours a day on "house calls". People would ping me and I made the rounds advising them on Windows issues.
It was focused time. No one needed my help much of the time, but when they did, we could work through a problem quickly and they would be better equipped to handle it on their own in the future. They always "drove", I just watched and discussed and helped troubleshoot.
It was really great. As you said, what made it work was that I was there when someone asked for my assistance, not just because "pair programming" was the thing to do.
If I were to give any advice to dev leads/teams/management that wants to introduce pair programming, it's good to put people of differing capabilities and expertise together. That way there's some value being added, and you're spreading around the arcane knowledge of your platform.
I wouldn't go so far as to say recurring sessions are always bad, but I do think that not all tasks benefit from having a pair work on it.
When I have been very attuned with my teammates in terms of the system we were building and how we were building then pairing sessions became much less valuable on work that was very low novelty and was some iteration of a well-established pattern.
I don't think it's always worth pairing. Easy work that doesn't need expertise is best done solo.
I acknowledge the "velocity" accusation; I've never seen a pair work faster than two skilled solo developers. But the quality of the output from a pair is generally a lot higher than that from a solo coder. It really does help to have someone looking over your shoulder. I've not seen a comparison of solo and pair velocity that takes into account code quality, and debugging and bug-fixing effort.
Did it for a long week (about 80 hours actually) when we were under a very tight timeline to get a product out the door - I actually thought it was extremely effective and productive - gained months worth of learning in a very short timeframe.
On the other hand, no way would I want to work someplace where it was assumed you would pair with someone all day every day.
I can see where the author is coming from, but I have also had a few good pair programming sessions.
Pair programming where one is more of a mentee instead of a reviewer should be useful to upskill the mentee so the pair are at more similar levels.
Sounds like an exception, not the rule. At least, I've never seen two people who coded together all the time. Not in the 20 years I've been a software developer (in both startups and in BigCorpInc).
We then spent every day of the next 2 weeks on near 8 hour videocalls developing some remaining features on his plate. It was an extremely effective knowledge transfer process. I learned plenty about this bizarre program and it's nonsensical logic, able to figure out future problems, and ended up as one of the main bits of glue keeping it all from collapsing. I also found it very rewarding to work that closely with a more senior developer, got a bunch of more general advice, had some interesting tangential discussions, and made a friend. Also got plenty of advice to leave the shitty company and it's terrible software asap.
I dunno if I'd want pair programming day to day, but it was a great experience at the time, and made my entry to the role much smoother than anyone elses.
The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it.
Even so, I will still not do it 8 hours a day. Probably 6, to give you time to do other stuff, like investigations, admin, ...
It is intense, but--at least in my experience--it was also very productive. You basically can't/don't ever slack off. And I learned a lot from the other developer (mainly about various tools). Things that theoretically I could have learned on my own but in practice I probably never would have.
If I had it to do over again I would definitely choose to do it again.
I think this is the best part of PP, its a great way to avoid procrastination.
Brain sag still occurred though.
Sounds like a real professional, you lucked out. The standard case is to just inherit that garbage and pray to god nothing breaks when you touch it.
Another potential disadvantage is that you may have been influenced by their methods and not having looked at the code independently, your own insight and input may have be limited.
And given the highly unintuitive nature of that system and the rushed training, there was plenty of room left for insight and input without requiring the same initial period of confusion and frustration that caused him and the other devs to have such a negative and lasting view of the system.
And more generally, I'm not sure why you feel the need to poke holes and find potential negatives in what was a positive training experience. Especially when what you've said could apply to any kind of training, and disregards the situation as described.
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.
I think it's bad because it shows a lack of understanding of metrics: The only valid productivity metric is code that works, and that everyone agrees does what it is meant to do. Code that does what it is meant to do without bugs is worth a lot more. Try quantifying that. I dare you.
Counterbalancing that is time-to-market. Expedient hacks are worth a lot, too. That you can, sort of, quantify. Risk capital costs a lot more than cash flow. Do your coders understand that?
Where to use pair programming? Probably not when you are racing to find product market fit. Possibly yes when you can lose existing customers due to a nasty bug (that may have root causes in early stage expedience).
Avoid dogma.
Like standups and pointing, it feels like a patronizing exercise we only force on devs.
Penn and Teller develop their tricks together. Two-seater attack aircraft are a thing. Rally drivers have a driver and a navigator. Apprentices are taught in part through pairing.
> Like standups and pointing, it feels like a patronizing exercise we only force on devs.
There's truth in that. On one hand, many of our practices is formalised problem solving under the (non-)constraints of software. Others are cargo culted, clueless, patronising and painful.
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 "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.
> Pair programmers tend to give feedback that's more appropriate in a design or code review.
What's his evidence? Why is it more appropriate there (after the code is written) than here (before/during)?
> For the pairs that follow this, the only feedback that's left tends to be bikeshedding or stylistic, both of which kill velocity.
That's, um, bullshit. Pair programming can pick up mistakes before they propagate, which increases velocity.
> It's like having a backseat driver.
I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.
> Alternatives like code reviews, design reviews, and general documentation are much better 1-to-n ways to share knowledge instead of 1-to-1.
Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.
> In addition, most of these alternatives be done asynchronously.
And this is better, because...?
I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.
That analogy is just yet another way how to shut up people who dont like the process.
In that case explaining why you like anything is a way to shut people up who don't
No. It is just that specifically agile has a way to responding to people who dont like something with very very handwavy explanations that feel good, but dont really mean anything. Explaining why you personally like something is entirely different kind of communication. Explaining why you think something works well is also different. But, going into "this makes sense, because two people make sense in rally racing" is neither of those.
Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
Perhaps unintentionally, a good analogy for traditional software teams. Eleven players, one or two stars, the other players mostly looking good because they can pass the ball to the top players.
In the end, all analogies suck. Pair programming is a pretty unique situation in the workplace, it works great for some people, others will never like it. It worked for me because I was kept on task. It may have slowed down the top performer but that person appreciated the company. Overall I think it made our team of 8 at the time more productive than they’d have been with separate assignments, and it really helped with team cohesion.
But, the non star soccer players in competitive teams are significantly better then what you imply. And do way more work and have way more knowledge.
There seems to be two directions of analogies here. One is arguing from subject to analog. “Programming is like rally car driving so we should act like they do.” Pretty crummy argument. I’d have no answer to your “why rally car?” question.
The other direction is explaining from subject to analog. “Strong-style pair programming is like rally car driving.” There’s much less of a claim here. I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding. So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about (not that it’s the most similar context).
In the latter case, the claim of fitness is separate from the analogy. “This method is useful. It’s like one rally car drivers use”. There’s no “because” in there.
It is fair to guess that nearly no one here ever sat in rally car. We know it has navigátor, but we don't actually know what navigator exactly does. And I genuinely don't see many similarities. It seem to be more about split second decision making in situation where you need to speed up or slow down toward turn.
Did you read the link I posted? The essence of the idea is you have one person who takes physical action, makes small decisions and take orders. That person is called “driver”. You have another person who makes larger decisions and gives orders. That person is called “navigator”.
The dynamic I just described is true of rally car driving and strong style pair programming. It’s not true for most pair programming or most other types of driving.
> Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.
I think PR reviews can be a resource for other engineers on the team to learn from beyond just the PR author. Granted, I think pair programming can probably deliver these lessons more effectively since you can have a live conversation about it and clear up any confusion there.
>> In addition, most of these alternatives be done asynchronously.
> And this is better, because...?
I don’t know the author’s feelings here, but I think this makes some sense in the context of the rising popularity of remote work. It isn’t necessarily a given that you’re in a similar time zone to your teammates.
I’ve also been interested in the topic of async work throughout the pandemic, with companies like Gitlab and Doist as examples who also evangelize the practice. I’ve pushed for some of those async practices on my team at work but feel like we’ve had mixed to little success with them.
So I agree with your skepticism of “async is better”, even if there was some reasoning provided.
I'd not done it much in the past but recently seen it done more and participated more - each time it's been useful. I paired to deploy some work, and having both of us work together was really helpful as we could talk through issues we were seeing as we went and it taught me more about infra & them more about the project.
When it comes to novels and art though, there's a focus on producing one persons imagined work, edited and helped by others. When it comes to programming, particularly in a company, there's a problem to solve.
Is it common in other fields of engineering to say that only one engineer can work on a problem at once?
> Individuals do these things all the time.
Individuals code alone all the time too. What I'm commenting on is the idea that programming together with someone is terrible.
Well one thing you need to consider is that most software is not written in small, artisian batches but at scale. Pairing is one way to promote doing development and all the things you mention at a greater capacity than the individual.
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.
Sometimes it helps me to have an external force help direct my focus.
It honestly feels like torture to me.
Switching tasks lets me reset from this state well enough, so I consider it essential coping.
What's great, though, about getting some work ready, creating the PR; and then waiting .. Minutes? Hours? ... days? who can tell? For a response.
if you're wanting "productive", that isn't it.
Yes, the system's productivity is not about maximising the uninterrupted productivity of person A, or of person B either.
Sending a whole pile-up of PRs isn't a great solution either.
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.
If two people on a team regularly contribute to a repo, one person likes to work on feature A, and the other feature B, and all of a sudden, the feature B person leaves and never comes back, that will kill velocity. Even if feature A person has been doing code reviews, a code review is much different than being aware of the system and continuing to improve a feature. Now person A has to either read documentation (which is, for the sake of code writing, a 0 velocity), or take larger tours through the code to figure out why a feature is how it is, and what needs to be done.
So the big question for anyone is if they want to focus on velocity/lines per day, or consistently smooth development. You can get both of those things when everyone is doing their own tickets, but that will immediately stop as soon as there is a change in your team.
I don't think pairing is perfect, or mobbing for that matter, but it does give clients a more consistent/smooth experience if they are okay with paying more for quality than speed. It does take the right kind of people and the right kind of project, just like any problem and tool set.
Code reviews in real time, in situ.
"White board discussions" in real time, in situ.
Learning how someone else codes/debugs.
These are all worth the price of pairing up engineers in my mind.
If we're talking agile development, I would love it if all engineers could get paired up for at least one sprint a year. Especially less experienced or new to the team engineers. I suspect it will be the pairing experiences that foster the most professional growth.
That's kind of subjective and I don't think I could prove its usefulness on graph paper to someone who isn't convinced, but I think it's real and significant. (and hence I'm curious if people who have mobbed a lot agree)
i also find paring to be useful when troubleshooting or working on a hard to find bug.
pairing shouldn't be the norm, but it can certainly be useful.
What is higher depends on a lot of details. You will see a lot of completely different experiences, all real, none alike.
> Pair programming can pick up mistakes before they propagate, which increases velocity.
Notice how it's "reduce bugs" twice with some other hand-waving qualities thrown in. Even if you have some solo developer write code with a bug, having another developer go through and fix it is a time saver over PP for all the code that was not error prone. Then we have the metric mixing issue of measuring developer code quality, over time, when mixing more than 1 person in a task.
> And this is better, because...?
Because you can avoid paying for idle time. The most common quality of pair programming team (considered productive or not) is watching one member waiting to see the other write out the function and functionality that was already agreed upon. Developers already do this when they have a tough problem. They invite others to talk and look through the code, ad hoc.
Pair programming has already been tried by a multitude of teams across decades and it does not produce results that have driven it's widespread adoption. End of story.
But.
This is still the best way to exchange knowledge and produce code when normally you would need a code review.
Pair programming is not a waste of time. It does not cost twice as much -- it actually costs less.
It costs less because having another person working with you cuts all the procrastination and keeps things in focus.
It costs less because now you have to discuss every part of the design with another person which is likely going to lead to better design.
It costs less because if one person doesn't know it or spot it, the other person will.
It costs less because you get immediate knowledge transfer and two people who can continue the project. Things can continue moving forward even if one person gets sick or leave the project.
It costs less because people learn new stuff crazy fast when they can observe other person doing things they don't know.
It costs less because actual people (like me) like to work with other people. It is fun.
It costs less because code review is a shitty process where 99% of people fake they made a review and only pick on stuff that immediately stands out rather than actually trying to thoroughly understand and analyse the change.
Unless you have a brilliant developer that can do everything by his/her own with no help or review. Consider yourself lucky.