Pair programming is really good but man it burns you out fast, when I did it even if it was just for a few hours I would be exhausted afterwards.

@Peter Mortensen thanks for the spellcheck. See if you'd been there when i was writing we could have saved all this work to communicate the bug and correct it after the fact. ;-)

@@mwwhited bingo.

Is it tho? When it comes to critical issues in production, the key factor is speed. Regardless of the Pair Programming you will always assign this part to the most experience developer (or the fastest one) so it can be wrapped up asap.

@@miledavitkovski1343 critical code issues in production should be an incredibly rare occurrence, unless your team has awful practices. Even so, two people used to working as a team could solve it quicker than a single person on their own. However I would not switch the driver and navigator around if it was urgent to save time.

We had really good buy-in from our users on a project where we paired. Some people were dubious about whether it was value for money, but we were defended to the hilt by other managers - not ours, those of the teams consuming our systems - who pointed out they could enter the bullpen at any time, no matter who was there, and get an answer to any question about the product. That said, it's been a long time since I got any enjoyment out of pairing, I mostly find it to be a way to keep us docile and on the feature treadmill. I'm no longer a fan.

That seems a cruelty to do it 8 hrs a day. I'm introducing new concepts like this to my team and even 2-5 hours a week should be sufficient to get a value add

Yes, as I think I said in the video, there will be some people that will never get on with pairing, and you have to figure out how you are going to cope with them. My experience is that after trying it properly, for a couple of weeks, not for a few minutes or a day, then the majority of people enjoy it. My highly subjective, extremely approximate, estimate is that only 1 in 10 or maybe 1 in 20 people are serious hold-outs if the company/team culture encourages pairing. You do have to overcome the inertia of not doing it to start though, which is why it needs a bit of focus and commitment.

As an introvert, I don't think being introverts have anything to do with pair programming. Introverts don't like much interaction, true. But we do crave intimate interactions and those that are close to our interests. Pair programming offer both: I can talk one on one with someone who has the same interest with me, i.e. coding. It's no different than two buddies playing video games using one controller, the good old time. Starting out with a new team member could require time and of course doesn't guarantee to work out but it's not the problems brought by pair programming. It will be much easier if you (and your partner) both have an open-minded/learning/sharing mindset.

@@thaianle4623 I don't know man. It felt quite draining when I was pair programming with my supervisor. I just prefered the daily meetings in the morning, just walking up to him or coffee talk.

@@chudchadanstud a supervisor, or anyone higher in a hierarchy than you, is not a good partner for pair-programming. It's natural that you will feel stressed, like if you are in constant scrutiny about your work. Everything is much smoother when you are paired with an equal.

@@thaianle4623 With the shuttle difference that programming is a job, not a game, and a colleague isn't a friend, although few might end up being it.

But this exactly why pair programming is powerful. You identified a weakness in being able to describe your technical choices, learned about another teammates approach

There was some research into "flow" and pairing back that the start of this century, I can't find it at the moment, but as I recall it said that pariing significantly enhances the duration of flow. That has been my experience. As a result pairing, when done well, is quite tiring. By far the most productinve teams that I have seen have all paired.

I experience flow more often when paired. The problem I run into is that people resist pairing and are magnetically attracted to working alone. The extra work I have to do to get people to pair is the problem, not the output of the pairing itself.

@@andrewadkins8440 Well this is a very interesting idea. I really cannot conceive of two minds being so perfectly synced as to enter the flow state. If you are able to achieve this then I can understand how this must be very intense. I've found pair programming useful for sharing knowledge but never approached anything like flow .

@@_winston_smith_ This is my personal experience. I think the real lesson here may be that we should experiment with our teams work habits and attempt to dial in on methods that work the best for them. If working solo is best for you, then I see no reason to attempt to force something else to work. I should note I find it most helpful when I am working on problems that are at the very edge of my ability. Where just attempting to come up with the solution is exhausting mentally. Having a second person to talk to makes it easier by allowing us to share the mental load and makes it more fun which keeps me more motivated.

I bet, you never really tried pair programming for any significant time. Only practice is the criterion of truth

I don't think I said anything about "forcing it on people". I agree, best not to "force it on people" but the data, and my experience, and the experience of many teams that I have seen adopt it, is that this is a better way to work for the organisation, and most people find it, personally, a better way to work too. If you think that this is about seeing people as "resources" you are missing the point.

​@@ContinuousDelivery If the decision is taken that your team will now practice PP, even if it isn't "forced" on you, the implicit pressure to join in is de facto coercion. I've been on many teams now that have attempted PP, and the number of times it was a success are far outweighed by the number of times it was cargo cult nonsense, with some manager quoting Beck verbatim and acting like it was his own work. Actually a lot of agile implementations are like that, as you are no doubt all too aware.

Good points. PP's acceptance must highly depend on the local culture and the individuals. Even if it is not always the intention, PP may have the effect that programmers - the ones who know their stuff - may have a feeling that they are exchangeable resources who are even not being trusted in their quality of work. It is defensible if you hire only juniors or students for a project. There are also studies showing that people can be motivated the most by trusting them and give them responsibility. About "studies" and "experiences".. you know, when you work with quality people on a project that turned out to be successful, it may become successful because of a method and despite of a method :)

100 percent

I have the same problem as a software developer. I've been at my current job for 9 months and still regularly run into things that senior devs understand about our code (complex enterprise system) but haven't shared with anyone - not out of maliciousness, just they worked on it alone and didn't document anything. So it's in their heads only 😖

That is awesome. That is how it's supposed to work. Good lads. There is this saying in the IT-industry - "A senior engineer's primary job is not to write code, it's to create the next generation of senior engineers."

I so agree. Agile itself is disastrous and very cultish, even using terms like ceremonies, rituals and artifacts. Middle managers and mediocre programmers who would otherwise be surplus to requirements cling to it like a drowning man on a log as it lets them piggyback off the abilities of others by all being "in the same team".

@@_Mentat Agree 100% - and very well put. Your point about middle managers etc. piggybacking off the abilities (and efforts) of others is so true. In the project we have just inherited, we submitted technical queries to the dev team in September 2020 (ten-day turn-around). Of course, they had to be submitted to '(non) management'. To this day, the queries remain un-answered. Eventually the end client twigged what was going on, and we've inherited the entire project. We recently spoke to a couple of the original companies' devs 'off the record' - they never received the TQs. Had they received them, they could have answered them the same day. However, if management had *actually* passed on the queries and passed the answers straight back, they would have revealed themselves to be nothing more than a useless layer of (non) communication between the technical experts. An impediment, rather than contributing any value, and also jealously guarding their own domain to justify their existence and ultimately keep themselves in a job. I realise it's a very negative view, but it's not a view formed from any knee-jerk dislike of the agile concept. It's just that my experience has *shown* it to be the very opposite. There may of course be agile projects that have worked well, but I've *never* seen one.

I've worked as a project manager with a team of 60 devs and testers (before test automation was was as powerful and mature as it is today), and it was a good experience, delivered on time and about 20% over budget (which as a PM of decades of experience I regard as a win ). The programming teams were teams of about 5 or 6, with each having their own scrum lead and daily stand up. I attended a stand up of stand ups every day, just after the individual team stand ups. It worked very well. Large amorphous teams of programmers don't work. The hard part is keeping a large team running harmoniously, and avoid too much management intervention beyond the project management. Company culture can kill agile development, and I've seen what you're describing elsewhere.

I can understand that, and I can say that the times I've done this it hasn't been a problem for me. This can be very true when someone comes and asks me an unrelated question. But when pair programming with someone, this isn't a problem. It might be that you find the social interaction weird and uncomfortable enough that it essentially serves as an 'unrelated question' and distracts you. It could be that you've paired with people who themselves don't know how to focus. At any rate, if I were your manager, I wouldn't force you into it. I do strongly encourage you to figure out what's going on and if there's a way around it because he's absolutely correct about it's benefits. I sort of don't like pair programming myself, but that's mostly because it's kind of exhausting. I will fully grant that we produce much better code than either of us could alone, and that all of the benefits he list do happen.

I find the contrary - the worse the code (the more I need to hold in my head at once...) - the more beneficial pair-programming is as you can share that burden and you have someone to validate what your thinking.

@@edwardcullen1739 I agree, it also helps me miss less. Meaning I don't nearly have to double back and fix a little logic issue. I don't do pair programming often but i do enjoy the time I do. I usually feel like I end up learning more this way but yes it does drain you.

You're supposed to be willing to trust your partner to help you with that load, instead of painting them as a distraction. This is as much a social as a programming exercise.

Why don't you switch to observer, and let the other person do the code writing? You just explicitly said you missed the most important point of pair programming: knowledge sharing and learning. As a side note, IME, whenever you have such a situation that you need to keep a huge context in your head to work on some code, there's something wrong with that code. Such code always lends itself badly to testing - tests have to somehow model the same context you keep in your head - and as such is at high risk of containing lots of bugs.

Studies based on students are worthless on professional teams where developers typically have 5+ years of professional experience. Students are often learning the basic idioms and patterns of a language. A lot of students don't know how to use source control systems. So their experience doesn't translate to the professional world, let alone high performing teams compromised of the top 10% of professional developers.

Style conflicts shouldn't be a problem.(Though i see how this part would be, part of the 'getting used to the practice'-phase) Either the navigator spots/knows an objective flaw in the driver's style. (great, problem solved, but unlikely) or asks for some explanation on why (great, learning is happening) Disagreements on styles will happen (just as they do without pair-programming) and you need a way to resolve those (not the difference in style, but the disagreement/choice which to use. just as you need to do without pair-programming)... so why not default to the same solution as 'without'?: If it is merely a difference in preference, discuss what needs discussing but ultimately: - if it is small enough to resolve outside of a refinement - and good enough to pass a code-review (possibly with the corresponding 'non-blocking' remarks) driver's choice. As for the 'validity of using student' Agreed this probably makes the 'numbers' probably more positive than they would otherwise be. It doesn't fundamentally change a thing about the points in the video. 'these are the reasons it's useful for non trivial-grunt-work' 'don't use it for the trivial-grunt-work tasks' All that changes between 'students' and 'programmers with decades of experience' is where the line of 'trivial' lies. If your work consists of >80% trivial pair-programming won't work... true. But if that's the case pair-programming is probably the least of your concerns. My main concern, even over the discomfort of switching approaches (to a more extrovert one) (which probably will pass) is how 'buzzword-heavy' (and overarching) the approach is, leading to the decision of what counts as 'trivial' being made by a non-developer.

I think it can be useful but not all the time. In my experience (as a student), pair programming have sometimes not worked at all, other times been about as efficient as programming separately, and a few times been very effective. When it worked best was when complex code (compared to our knowledge) was written and both participants had about the same amount of experience and knowledge. Those times was really fun and probably the most effective learning experience I’ve had in university. I think pair programming is very useful sometimes, but I think it should be used selectively.

@@PatrikKron - That rings true. I've also found pairing to be useful when you encounter something new or some convoluted legacy code. Or when you just need another set of eyes on your code. That kind of common sense approach is missing from what consultants are selling.

I feel the same way. Pair programming is amazing for solving complex problems, but it's exhausting. You have to do everything you usually need to do, while at the same time engaging in constant communication with someone else, all while you try to stay focused on the task at hand.

Sounds like you're introverted? Anyone who tends to get peopled out is going to get worn down.

This.

Nope. Quite the opposite in my experience. Managers hate it because as Dave says they feel they've got two people ding the job of one. Developers like it because it enhances the social experience of programming, allows easy exchange and evaluation of ideas.

it is really good for debugging or fixing difficult problems but a waste of time or even disruptive for day to day programming

Like lots of things it takes a while to adapt to it. It is certainly true that there are some people, in my experience a minority, who really don't get on with pairing, but most people that I have seen try it for any time (I generally recommend that you do it every day for a couple of weeks before deciding if it is for your team or not) think it significantly better than working on stuff alone.

Continuous Delivery I respectfully disagree. I worked at Intel once with another engineer and he literally put me to sleep. He hogged doing all the coding and I did not enjoy working with him. It’s also draining. I don’t like continually talking. It’s very tiring. I ended up quitting the job because of it. It left a bad taste in my mouth. Most programmers don’t get on. A lot of times I literally want them to get out of my space or I will punch them in the face. As the other person said, good for debugging, waste of time otherwise. I’m no rookie either. I have 25 years experience as a software engineer.

@@jackb348 "He hogged doing all the coding " that does not sound like pairprogramming. As Dave says in the video, with PairProgramming you swap roles frequently. What’s you descibe here, sounds like a programmer showing off with an audience, at best that at's life code review, yet as you experienced that almost never works... My advice would be, try to pair with multiple other programmers that have experience with pairing.

​@@btm1 In my experience it's even better for boring stuff. As with boring stuff, people tend to get distracted easier and make stupid/sloppy mistakes, then you then end up looking for a long time. With Pairing , it's harder to get distracted and your pair will catch at least half of the errors while your write them...

Well, I think that there is a "question about it', but I agree that not everyone likes it. Have you ever written a song or a book or a script for something? Many people find these activities considerably easier when they work with someone else, in collaboration. There is something about bouncing ideas around that can, certainly in some cases, amplify creativity. Your description of it sounds to me like some one who has never tried it. Nearly everyone is skeptical before they do. It is also possible for pairing to go wrong, some teams and/or indibividuals find it impossible to do it in a way that doesn't make people uncomfortable. My experience has been that it has always been a positive for the teams, and people, that I worked with. My strongest, longest lasting friendships that started at work were with people that I worked most closely with, paired with. We also created the best software of my career. None of this means that it will automatically work for you or your team though.

@@ContinuousDelivery I am friends with several authors and none of them write in pairs.

@@ChiefsFanInSC Exactly. For a song, maybe the lyrics and the drums and the guitar might need input from different people. But writing a book is a solo endeavour, and IMO code is too. (You already have to satisfy the compiler, never mind the person sitting next to you who wants to argue over where to put the curly braces). For design discussions, bug hunting, mentoring, reviews: sure, they might all be group activities, but writing the code? Let me focus on doing that and that alone.

Sorry you didn't enjoy it. I am the other way around now, I miss pairing when I code alone.

Hi Matt, I think you have a point. While I program in pairs for 60% of my time and generally enjoy it, it demands a level of attention and responsiveness that I find difficult to maintain for more than 5 hours. My recommendation is to try it out where you or your coworkers find it is promising. Pair programming does not not work when it is forced from above but I find it evolves naturally in autonomous teams and in a collaborative culture. I also find that my best work is nearly equally distributed between pair programming and programming alone 'in the zone'. Any organization that forces one mode of work over the other ignores oportunities and therefore acts foolish. So for managers and consultants my advice would be to support collaborative work, empower your teams, and abandon your disfunctional behavior. In those circumstances pair programming may work. It definitely works for me. Kind regards, Oliver

You actually write code 8 hours a day? Where's your thinking and design time? "Talking in your ear" sounds like you don't like the people you work with, more than you don't like pair programming...

Yes, I used to call that "Pairing-Lite". I think that everyone does that sometimes. "Pair Programming" is really when most work is done this way.

Totally agree here, as a student I have also had a few very great pair programming sessions where I’ve learnt a lot and had better code as a result. Other times though it have not worked as well. I think interpersonal dynamics determines almost all of the result.

grüße

Welcome aboard!

Well for me personally this really exhausting. I can only deal with a certain amount of human Interaction per day.

For me pair programming (when working on my private projects) is mostly a really great fun.

I don't know what Pivotal do, but on the teams that I have worked on, we usuallt operated a fairly flexible system. There were core hours, usually 10 'till 4pm, depended on the team. The expectation was that you were available to pair during those hours, but what this meant was that if you needed to be somewhere else during those hours, your responsibility was to tell the team. That's it! It didn't mean you had to be there all the time, just that you communicated.

It requires overlap, not mandatory hours. My team is spread from Ireland over to California, and we pair in thing. We don't all pair with the same people all day, or even all the time, but some people in the US come online very early, others in Ireland work later, and it works just fine. People jump on a call, screen share for a bit, and chat over things. You don't need everyone on the same hours, you just need a predictable overlap.

@@talideon - Pivotal need to hear that. They seem to demand 100% pairing. I've been "pair programming" quite a bit lately since I'm learning a proprietary Angular framework. It has a long learning curve. One hour a day or so of screen sharing is typical. I've also found that I need to think things through on my own before I have really learned a new API. Listening to someone else talk me through it is OK for an introduction, but I have to work with it myself to really learn an API. Having to recall things from memory is an essential step in cognition.

Yup, but in other studies this is backed up with more quantitive measures, tests written before the code task was started to validate the correctness of solutions for example. In all studies that I have seen, the pairs significantly outperform individuals on quality.

Yes, exactly! I can remembering confusing the hell out of management when someone left our team, and our boss said, "how much time do you need for handover" and I said "none, but we'll need a party to see them off". 😁😎

If you would like a helpful guide on Pair Programming: www.subscribepage.com/cd-pair-guide

Thank you 😁

I think that the first point to agree on is that this analysis, though very common, is wrong. It doesn't save time, money or improve the quality of our output. So when orgs (and people) take this "narrow view" they are making a mistake. If we do the things that I generally talk about we create higher-quality software more quickly and have more fun in the process, and the orgs that do it make more money - that is what the data says! The hard part is changing people's minds, and data and facts aren't enough. One of the techniques that I have used is to try and find a problem that the people saying "No!" have and helping to fix it. You don't change people's minds by telling them that they are dumb, you need to find a way to help them. None of this is easy!

He has some links in the description for further reading, however you can do your own search on Google scholar and you'll find academic papers on the topic, some of which are open access, the peer reviewed ones will likely be behind a paywall. Often, paywall papers can be found for free elsewhere if you put their titles into a regular search engine.

@@not_ever there’s also a HUB of SCIence that one can use to get around paywalls

Glad you enjoyed it!

You may find my post on "Pair Programming for Introverts" interesting: www.davefarley.net/?p=267

I'd say "whatever works for your team" too, but I have seen pair programming work for many teams. It is certainly not for everyone though.

@@ContinuousDelivery indeed, and I can see the benefits when it does work. I guess my point was just to say don't be too dogmatic about it (because some companies are)... and don't expect it to work for everyone.

@@Greedygoblingames Yes, I certainly agree with that. I try hard not to be too dogmatic abount anything. I think that you can argue me out of any of my beliefs, but you will have to work hard to convince me of some of them. Pairing is one of those, I'd need some good evidence to shift my view that it is a higher-quality, more team-centered approach. But there are some people that hate it! I once led a team, when we hired people we told them that we did TDD and Pair Programming, and if that wasn't for them this place wasn't for them. We hired someone who was very good, and really, against his preferences and instincts, worked hard to make it work. The best he ever got to was to relunctantly pair some of the time. That was an acceptablce compromise for all of us. Not ideal, but it worked ok. He was a very good programmer, I still believe that we could have helped him to become a great programmer if he could have worked better with others, and so been more open to learning - but we all ended up being comfortable with the situation.

@@ContinuousDelivery totally agree that pair programming will only work for certain teams. For those teams that cannot get pair programming work, it seems they're lacking of either respect to each other/collaboration/non-judgement/open mindsets which could hinder the team effectiveness. Does such team even care about effectiveness?

Glad it was helpful!

No, the mediocre partner is amazed at what "they" have produced. Someone else did the work and they share the credit.

I think that depends on where the "professionals" work. It certainly is employed, and does work, in some professional settings.

Marianne Williamson's interview with David Rubin has always been my inspiration of how you can be criticizing, charismatic, and caring without coming off as harsh or too judgemental

First of all: I am not work as a developer at my work. I am a production (plant) manager, not in the software industry. I consider myself an introvert. I do programming to aid my (our) work, but that's not my job at all, it is just my solution to do things better, easier, faster, higher quality. And we have an employee who isn't supposed to be a manager at all, we employed him for a very specific role, which does not involve that much of thinking. But I have quickly seen that he is capable waaaay more. I have seen him so great and smart that I started to teach him everything I know in the first week, and he quickly became a deputy. This was 3 years ago. To this day, we organize the same set of work together, both of us likes to share his idea and thoughts and we don't race who is the better, we both appreciate the help of each other, trying to establish the best set of rules, methods and everything. The outcome is not just the simple mathematical union of our individual best, we both may have stalled sooner or later under the pressure, but this way we motivate each other and improve faster. So eventually we naturally ended up in pair management, so to say. Our output might not be double of our individual output, but the quality, enjoyment of work thus sustainability is certainly more stable. Did I convice you? Maybe not. Because I don't see this easily achiveable either, if there are no right set of people to choose from. I consider myself a very unique thinking person, I maybe too open minded and curious and the area where I live/work isn't really filled with people I can really share my thinking process with. So I never imagined here I ever have a college at this level. I guess the same applies to pair programming. If the employer does not choose the right set of people, or someone are too unique, it might not pair well to anyone. Which doesn't mean you should get rid of him, just either try to find an equally unique person for him, or let him shine in some other way, because boring pairing might just kill his motivation completely.

One more thing to add: I also somewhat disagree on fast rotation. Involving every developer in every single aspect of a code might sound good to an employer, as everyone become replaceable. But it can have a side effect. Everyone becomes a machine. Problem in, some chruncing, half-assed unfinsihed solution out, next day, goto 1. The enthusiast developers are driven by success. Not the company's, at first, but their own at first. We see the task as a challenge and we want to solve it, and we want to see it working to enjoy the work we put it into. If the rotation removes this feeling, if my brain is still thinking on yesterdays problem but I HAVE TO do something else and never see that problem again, that would completely demotivate me and would be boring to work this way to me.

Yeah, it's a "clickbaity" title, the only thing I didn't like about the video.

Glad it was helpful!

Painting, when done on a large scale it is often done with, sometimes very large, groups of people. Scultping, the same - one person didn't sculpt a whole cathedral! Composing, all sorts of variations, but many of the most durably successful writers of popular music write in pairs. Lennon & McCartney, Benny Andersson & Björn Ulvaeus (ABBA), en.wikipedia.org/wiki/List_of_songwriter_collaborations Writing, lots of collaborations here too. Actually though none of this matters too much because we aren't comparing like with like, I think that you may be thinking "Creative == Art" whereas I disagree with that. I think Art is only one form of creativity, and a simple one in many ways. I think science and engineereing are also intensively creative. I would argue that science is the ultimate expression of human creativity, but it is more difficult because it is constrained. I can paint melting clocks, but they don't have to work! SW is creative, but in the same way that building rockets is creative, both still need to work at the end, not just be decorative. If you are writing SW to make something beautiful, and that is your only criteria, then sure, perhaps working alone is better, if you are building software that needs to work that is something different IMO.

Classical painting and sculpting were done by "teams". But it was very much students serving the master. Students were like spare paint brushes. And they didn't get their name on the finished work; there was no question of equality. I will pair program, but unless you've got my 40+ years of experience, I type and I decide.

​@@ContinuousDelivery Let me clarify a bit what I wanted to say: I wasn't speaking out against cooperative work. That would be weird, as there's rarely a piece of software out there that's small enough to be done by one person. Just like a cathedral that employed hundreds of stone cutters, we cooperate with software. But those stone cutters didn't pair up for a single stone. One may have left out some details for another one to fill out ("hey Sam, I got another devil face here, could you do your amazing slitted eyes? Thanks!"), but they would do their "unit of work" alone. And just like with any collaboration, they stood together when they mapped out the motive, the pose, the proportions before each of them went to work on their own stone. But what I see with pair programming is that there is no "unit of work". Every time the chisel if positioned, every time the hammer strikes, we should do it together. Our "unit of work" is every single letter that is typed. That's nonsense. Nobody can get into a flow, or can even get to a point where they can think through all implications if what they are picturing writing. Unless the second person just sits back for 20-30 minutes and dreams about Fiji. There's a minimal unit of work one has to be able to write down before involving a second person. May it one method, one screen of code, once class or one feature. That depends heavily on the language and framework used and the current state of the project. But one character, or even one statement isn't it. As I said before, authors cooperating on books write chapters or scenes before sending them to their partners. They don't write single sentences (unless they want help/feedback/etc. for one specific one).

You are welcome!

Well people differ, of course, but in my experience the complete reverse is true. I find it more rewarding to celebrate success together with other people.

@@ContinuousDelivery Let me clarify a bit... It's not that I don't like working with others. I just HATE pair programming. When it is time to work together on something then I'm all for it. But the very idea of pairing is almost beyond oppressive. The idea of having someone sit at my desk, which cost me quite a bit of money, and pushing my keyboard and my trackball, both of which were expensive and are configured exactly as I want them, back and forth to satisfy some management fad is revolting. The keyboard is one of a kind. I completely designed it myself to accommodate my large hands and my carpal tunnel problems. I don't want to use a different one. I don't want to argue about my keyboard layout, the fact that my keys are extremely clicky, or about how you don't know why I use a keyboard with the keys in a well. I don't want to argue about trackballs vs trackpads. I don't want to use your laptop and I don't want to hear that my desktop with its 3 4k displays is old fashioned or that it is too big. I don't want to argue about you not wanting to use the text editor which I wrote and I certainly don't want to hear you bug me about not using some editor which I thought was horrible 30 years ago. When I want to stand I don't want to ask someone if they agree, I just want to click the elevate button on the desk. When I want to walk on the treadmill I don't want to argue about it. I want to just raise the desk and pull the treadmill into position. I don't want to hear that you hate my black office. I don't want to hear that you like it. I don't want to hear that you love my blue light bulb. I don't want to hear you whine about it. I don't want to fight about your rap music vs my Mozart. Almost everything that I have ever written that was any good was the product of long quiet walks alone along the river with only a pocket notebook. There wasn't a microchip within a mile. Am I supposed to bring you along and what if you don't like walking in the snow or the rain? Am I supposed to pretend that a main reason that I am there isn't because I know that there are no people within a half mile? Am I supposed to instead pretend that I am there for conversation instead of quiet contemplation? Software, is a craft. I missed the point somewhere about Leonardo passing a paintbrush or a pen back and forth with a collaborator. I missed the point about Rodin taking turns on the chisel. I missed the point about Isaac Newton passing his draft of the Principia back and forth with Halley or Hooke. I missed the point of Dickens taking turns writing paragraphs of text. Craftsmen do not work on an assembly line basis. Craftsmen immerse themselves entirely in their work. Craftsmen work alone. I don't want to coordinate working schedules. I have started work every day for 25 years at 3:30 in the morning. Do you want to do so as well? I don't want to coordinate restroom breaks, coffee breaks, and lunch hours. I don't want to argue pomodoros vs flow vs deep work. I know what works for me and I am to old to change it now. When I first read Extreme Programming I thought the section on pair programming was meant as some kind of joke or something and that it was the result of watching the Star Trek episode about the Binars one too many times. I have never seen a more obvious example of management dictated babysitting. I want to do my work and know that you are doing yours. If you want to collaborate then if you are an exceptional tester with enough programming ability to write the tests as needed then I am all up for it. If you know an excellent technical writer then bring them along. We can do good work together and all be proud of our achievements. I just want to program the computer.

@@georged8644 Of course all of that is your choice. The practical things of keyboards and mice are easy enough to accomodate if they were the only barrier. On of my friends prefers a Dvorak keyboard, so we had a workstation with two keyboards etc etc. Personally I am a night-owl, so 03:30 start times are out! I have worked on a couple of teams, in the early days of XP that enforced pair-programming on any production code. I think that was wrong. My preference, when I was in charge, was to set the expectation that pairing was the norm, but to allow people to decide. I think that it is more, much more, than "management dicatated babysitting", but when I was a technical manager of technical teams, I know of no better way to grow and strengthen a team, but I persoanlly also find that, maybe not always, but often I write better code when I work closely on it with other people.

So true. OK for teaching but you're not going to do great work in a pair - the result will always be mediocre. The pair may pick up on typos but that benefit is not worth the distraction and the time you have to take explaining your thinking.

@@_Mentat That's not what the data says, (see the links in the video desctiption - and watch the video) and I built one of the world's highest performance financial exchanges (at LMAX) with pair programming, so it doesn't fit with my personal experience either.

Yes, I have done this. You can organise the refactoring step however you like, mostly, the person who wrote the code that made the test pass would start out, but collaborating closely with the "navigator" while doing so. My teams treated this as a sort of game rather than a hard-and-fast rule, so we'd do it until it didn't make sense and then swap people around. In reality, once you become comfortable with pairing the switching of who is driving and who is navigating becomes pretty fluid.

Yes, this is called "TDD ping-pong". :)

But what if you meet another nice person? Or are all the other ones in your team "seagulls"?

I am fairly introverted, am in the Autism spectrum and have social anxiety. I found myself mostly pushed by circumstances to do pair programming in university and I can say that it is an amazing tool for solving complex problems. You are not pairing to socialize, you are pairing to solve a problem, in that regard I don't think it takes as big of a toll as people would generally expect it to. It's also a matter of habit and trust. At first it may be hard to get into it, you may have issues trying to communicate with your partner or difficulty shutting down an idea. However, as you work together and build trust, this gets easier and easier.

I’d suggest research, and if it doesn’t exist, build it :-).

Jim, there are several tools to support remote pair programming, with rapid swapping of roles while working on a single machine. But we don't even need all that extra fanciness. Set up a shared branch, then push and pull. The driver shares their own screen so they never experience lag. qualitycoding.org/remote-mob-programming/

I may try and do another video on that topic. Remote pairing works pretty well, as in the other reply to this, just screen sharing of some kind is enough. I once worked for a trading company (lots of money) who paid for "always on video conferencing" to essentially, virtually, extend my desk into my team mates' desk in Chicago - big screen at the end of my desk showing them, they had a big screen showing me - that was great, but just sharing the screen and regular commits is enough.

Yes, that matches my experience too. Nothing fancy needed and it works almost as well as sitting next to someone.

Thanks for the replies. I was talking to a co-worker about how we could do this with our current tools. I've done some remote pair-programming using shared screens on Zoom and Slack calls. That works pretty well, but we've not swapped roles. We thought the shared branch push/pull technique would work, but switching roles wouldn't be as fast as moving a shared keyboard from one person to another. We thought this might work well with the Pomodoro Technique. Pair for 25 minutes, and then shift roles with push/pull after each session.

There's a cool feature called Live Share in VS Code that allows two or more people to collaborate on the same code without worrying about syncing or presenting. Changes made in one IDE appear in the others too. You can switch over control very easily this way and maybe even avoid branching.

Except that isn't how painters always paint landscapes or cabinet makers making cabinets. In both cases, in the olden days they would learn from a master. Who would be looking over their shoulders and guiding their efforts. Many famous paintings by the "old masters" were painted by their students. The Sistine Chapel for example. It is also not how pairing works, unless it is done really poorly. A good pair is sensitive to your thinking and will try not too interrupt it, leaving you to make mistakes and correct them yourself, and only pointing them out when you seem ready to move on, and have obviously missed them. Your descriptions simply doesn't match my experience of pairing. Maybe I was luck, maybe I worked on better teams than you did, but that means that we are talking about something other than inherent problems with pairing in either case.

​@@ContinuousDelivery yes, apprentices tend to do very well with a someone looking over their shoulder, and maybe that's why these studies done on apprentice coders show such positive results for pair programming. But when you're talking about adopting this concept in the professional realm, you aren't talking about apprentices. You're talking about masters with other masters hovering. That's a whole different ballgame, and a contact sport at that! I question the professionalism of anyone who suddenly becomes twice as productive just because someone is looking over his shoulder. A student? Sure. An expert? Nah, that guy was stealing company time. If pairing is meant to solve that problem, then it's just a peer-enforced micromanagement mechanism. Better to just fire the unprofessional company time thief than to turn the team into McCarthyism-incarnate. I'm with Woz on this one!

@@arithmetech Well I have paired with some devs that are generally thought of as "great", and while I agree that it is sometimes a "contact sport" but you get some great things that way. It sounds to me as though you have never tried it, because the idea that this is waste of time, even for experts, just doesn't stand up, at least in my experience.

@@ContinuousDelivery Excellent book, by the way. Your perspectives, engineering-based approaches and applied experiences are definitely worth consideration and application where they make sense. I think the same can be said of this subject, but with (at least) two caveats: (1) your data set is very weak and anecdotal, so, while interesting, it must be taken in that very limited context, and (2) the human behavioral/psychological components are extremely complex, and trying to shoehorn an individual into such a specific process is likely to produce a wide set of results when applied across a large data set. The apprentice argument is also somewhat specific. If one looked at, in the western world, the collection of great authors, composers (most aligned with our work, I believe), painters, sculptors, musicians, architects and more, while their work often involves some level of collaboration, I think you will find very few that generated their best work, literally hip-to-hip with another individual, while critiquing (or doing) their work. Back to the highly anecdotal, I have found pairing to be beneficial in more focused scenarios: ramping up on a new technology or process; up-leveling a junior team member; pushing through a blocking issue. Otherwise, I find it very disruptive and often the source of great anxiety, as it forces an artificial mental tempo that often does not match my own. In some cases I simply do not want to be forced to work near others I would have avoided otherwise (because of their odor, their habits, their fidgeting, and on and on). To take a high-performing individual and then force them into a process, simply because it was sold as another solution to everything wrong with software development, goes against everything known about human behavior and productivity. Yes, we all must negotiate relationships in our personal, family and work environments, but to sell yet another process as being superior to all current or previous approaches is somewhat ignorant. In the end, we are all individuals, and that is how a manager, an organization should approach their processes. It is like a dance, and balance must be found. I see so many cogent arguments why pair programming is not a good fit (and some bad or absurd ones), but keep seeing a more-or-less set of canned responses: you must not have really tried it; you must be doing it wrong. I think this is a bit disingenuous, it doesn't fit your usual approach to many other subjects and deserves caution.

Good question! Especially in the current Covid world! We will probably see more distributed working in future - and I am covering this topic in my next video!

Nothing wrong with starting easily, so I can’t see a problem in doing it 1/2 day at a time, if that works better for the team. I think you should try it for longer than a couple of weeks, so 3 weeks or a month is a good amount of time for the experiment. Good luck!

@@andrealaforgia5066 Fair point, thanks for it.

Depends on how "programmable" your Au pair is :)

Yes, I asked my followers on Twitter for their advice to people who are just starting out, I got a couple of hundred replies. Here is a video on their replies and my own advice to people in the early stages of their career: kzfaq.info/get/bejne/ntB5n7eSprPXkn0.html

@@ContinuousDelivery thanks for the assistance. Do you also have a Computer science /IT background ?

Yes, I am a software developer. These days I am a consultant, advising, usually big, companies on how to improve their SW engineering, but I spent 35 years writing software professionally, usually big, fast, distributed systems. I am also the author of a book called “Continuous Delivery”.

Get really really good at what you do. Look for domains (ML, security, UI, etc) that you are interested in and build domain expertise.

You can do remote pairing!

It’s even easier remote, you don’t even have to switch seats or breath in each other necks

@@michielthai9995 But you do have to constantly have a Slack session or similar open, which is fatiguing.

@@georgeonearth they key is that you do it for an hour or 2 max a day. It's same when pairing in person.

In the description for the video.

He has various videos explaining why he dislikes working in branches

Spend the 2 hours to solve the problem! Usually do it together as a pair, bouncing ideas around.