Understand the benefits of different pair partnerships Learn how to introduce pairing as an option for your team, and Identify anti-patterns and how to avoid them with my FREE Pair Programming Guide, which you can get here ➡ www.subscribepage.com/cd-pair-guide
I did pair programming in early 2000's for 5 years and I will avoid any job that does pair programming as a required practice for all development. Its great for mentoring and on occasion but nearly drove me from the profession when I had to do it all the time. We had several training sessions by Bob Martin from Object Mentor... so we did it close to "right". Bob even admitted that they didn't pair program much at Object Mentor (at the time I asked).
I usually agree entirely, but have mixed experiences with pair programming. I've had both positive and negative experiences, but more negative than positive. I understand that this may be highlighting a failing in myself, but I don't think that's necessarily the case. I'm quite an experienced developer, but in my very early professional years I was something of a maverick, and I came across as arrogant. Learning to work with others of various skill levels was probably a more important lesson for me than any other that I've learned in programming. Unfortunately, not all developers learn this same lesson. I've paired with other programmers that have a heavy ego, and are quite inflexible in the navigator role. I find this hideously irritating and have done an even share of biting my tongue vs standing my ground with them. I've also worked with novices that have the same maverick attitude that I once did, which is no less irritating. Ultimately, when pairing like this, I find it too often becomes adversarial. I might come away with code written to appease the pair, or a dissatisfaction with the result, and I generally dread doing the same again tomorrow. This is not to say that ALL pair experiences have gone this way, and I've had several which worked quite well. What HAS worked for me is teaming with another developer on a feature. A sub-team of two solo developers makes for a very interesting dynamic. Generally, you both get on and write your own end of the feature, but when either gets stuck they can consult with the other, which is far easier. If one developer has asked another for help, there is already an implied stance on who is asking for help, and who is giving. You may still disagree, but it's more rare that you do, and it's no skin to be asked for advice not taken. Further more, you're likely to step into actual paired programming when the situation calls for it, and without the adversarial environment. i.e. I'm now willingly pairing, rather than being asked to do so in some mandated rotation. This comes with all of the same benefits, such as the pair demonstrating how they work with the tools, debuggers, keyboard hot-keys etc. Pair-Team Anecdote: Around 15 years ago, I worked with a former Microsoft developer that was an absolute expert with the .NET framework. We were tasked with making .NET managed, and native code communicate with each other (IPC). When we first discussed this, I suggested using a windows API message WM_USER+ but the other developer had no knowledge of the windows message loop. I was a little taken aback at first to hear this from someone that had worked at Microsoft, until I realized that the .NET framework generally shields you from having to know about the workings underneath. I explained and demonstrated the loop, helped to look up win32 API bindings to create the necessary .NET invoke calls, and then spent two weeks back and forth with the other developer, sharing ideas which detailed the communication protocol and so on. What worked was that we were each the subject experts for our own piece of the code, but working towards the same goal. We could share solutions to memory management when passing between managed and unmanaged code, knowing that we could each rely on the other for the knowledge we needed to keep working. So, with no statistics but only personal experience to back this assertion. I would suggest that teams breaking into sub-teams of two developers is a far more productive solution, and, management can be told that they're still getting the work of two to put into their spreadsheets.
I loved the point you made about this helping LEARNING, this is an interesting framing for this. I'm going to try this with NON-programming tasks with some of my students and see if they can improve.
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.
@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. ;-)
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.
Me and a buddy did that in 1983 doing assembly on the zx81. Its amazing how different our styles are even just using the same dozen op codes. we still do as a hobby lol. Why rotate so much? I get if for homogeneity, and levelling up the team and all that but there's frictional losses and too hard to sustain IMO. I'd rather do through feature completion, then rotate (social factors)
I have enjoyed using pair programming a few times but most of the time it completely drains my energy, my creativity goes down and everything becomes rushed. Not sure about the issue, through.
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.
I don't like pair programming. The systems that I work on require a ton of context to be loaded into my head before I can begin mucking with the code. Having someone look over my shoulder and comment on everything I do tends to cause the context to leave my head. Maybe it's OK on a new project.
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.
I always found pair programming to be good in principle, but terrible in practice. It breaks the flow of code far too much and leads to worse code in my experience.
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...
I have found a number of caveats. Many developers are introverts by nature, which doesn't mean are anti-social, but constant social interaction can be draining to them over long periods of time. It can also lead to analysis paralysis. Very good tool for mentoring new developers though.
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.
Pair programming? How about pair team leads? Or pair managers? Where to start. Why is coding being conflated with teaching? Why is disaster mitigation being leveraged with pair programming? How about a pair being completely mismatched in skill set? Or when someone wants to code in complete silence? The sure path to insanity is to watch someone hunt and peck at a keyboard, trying to remember the key combination to delete the next three words and append a comma. I like your presentations, and this was well presented, but I couldn’t disagree with you more.
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.
While pair programming is great for sharing knowledge I have a hard time accepting the productivity claims. The mental state known as "flow" cannot be achieved when working in a pair. This state of intense uninterrupted concentration maintained for several hours is both extremely productive and also pleasurable as a programmer.
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've been really struggling with this in DevOps for a long time - everywhere I go, I end up on a "team" of individuals, working on disparate work streams, with very little day-to-day collaboration. Sure, for simple admin stuff, this is fine, but when you have to do something complex / implement something new, I often need to spend much longer on knowledge transfer (partly because of the junior nature of my colleagues). This is something I'm going to take a much harder line on as I think it really would be a Silver Bullet for so much; in the DevOps context, this would mean more like one person doing, the other documenting, which is at least a line I can try to placate the bean-counters...
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 😖
I ended up quitting one job because of pair programming. I am unable to maintain focus and concentration consistently over an 8-hour workday, and so it was difficult to match up with my partner. In addition, I'm quite introverted and found it draining to interact socially continuously over that period. I would often come home exhausted and just be unwilling to do anything after work, which was toxic for my social life. I wouldn't mind pairing once or twice a week for just a few hours at a time. In fact, that was how my friends and I often got through the barrage of homework assignments we were given in college. For me, I am more productive, mostly due to feeling the social pressure of needing to contribute to solving the problem at hand in a timely fashion. Working in a team has its own way of motivating attention. The way it is practiced in Xtreme Programming is intolerable to me, however, and I would never join a company that practiced it daily. The dream, for me, is a quiet office where I get about 3-4 hours of uninterrupted, focused programming done per day. So yes, I agree that pair programming works. It's just that I would quit due to having to work my brain so much harder every day. Since senior engineers are in high demand, I get to pick my work environment. Those who are more extroverted should definitely give it a shot - they'll probably find it enjoyable. However, those types tend to self-select out of engineering and drift towards management.
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
I loved this, and I always loved the idea of pair programming. However, in practice, both as a developer and as a tech lead, I've never managed to make it work on a daily basis like you recommend. I used it sparingly for onboarding and for when somebody is stuck on a problem. I'm super enticed by your experience, though. I'd love to see a follow up video which could get into the nitty-gritty of how to actually pull this off.
Been forced to do this at a new company for 3 weeks now and about to jump ship. No freedom, someone talking in your ear constantly. Doing this 8 hours a day every day is an atrocious idea. On a case by case basis; personally I’m about to scream and about to quit. 20 years experience and I’ve never had a more ridiculous experience ever. I don’t care about the productivity and code quality benefits, none of that matters if you’re not taking into account the psychological health of your developers.
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...
I find it utterly intolerable. It almost completely destroys concentration and creativity. Furthermore, it sucks all of the joy out of developing software and the pride of accomplishment. The only time I have ever seen it be effective is when tutoring another programmer or when assisting another one.
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.
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.
About a year and a half back I went to a Global Game Jam. I do not know anything about making games. For some reason I ended up with a couple of senior guys from the university. I knew some Java, but we used Unity, which uses C#. One of the seniors didn't code anything, just guided me. I ended up doing the movement for our player. The small game was pretty much actually. I still remember that GGJ fondly.
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."
freakCodeCamp Presents: THE PAIR PROGRAMMING COMEDY PODCAST STARING WILL AND BILL Will: You idiot! I said type "script" not typescript Bill: okay, typescript or javascript, whatever you say boss Will: Now declare a variable- you know how to declare a variable, don't you? Bill: I know how to do a backside arial, I've never heard of an "eclair arial" Will: This is a computer, not a skateboard, you idiot...
1) It might work well for juniors but not so much for seniors. 2) The studies are based on statistics, thus peer programming isn't for everyone. 3) Nothing can't beat a good methodology when it comes to learning. 4) Forcing people to work in pairs and taking into consideration the job rotation in the sector is like practising tango and changing dance partner very often; by the time you're in tune with each other, you need to start over. 5) Programmers aren't "dance partners", no one signed for that kind of stuff when joined IT. Stop seeing people as just resources to be squeezed in order to get more productivity. 6) People need time and space to research and explore so too boost their creativity. 7) Make it optional for those who want to work like that, but never ever force it upon people.
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 :)
Having worked on a number of agile and XP programming projects, all of which were disastrous, I have concluded that Agile and its off-shoots is nothing more than a cult, which has provided an opportunity for some people (the Scrum masters etc.) to make a lot of money, acting as the high priests of their lowly, sheep-like flock. I've realised that it works for people of a certain personality type (happy to follow) or for inexperienced engineers (happy to be on a team learning from more experienced people - it's good in this respect), but for very experienced engineers, it's constraining and frustrating. We have just inherited a 6 year overdue project from a large provider of critical national infrastructure. They had sixty developers working on the project in one form or another. We are putting 10 people on the project. *That's* how you do Agile (in my experience). Fred Brooks was right. Teams should be small, not large. When a team becomes too large, it becomes the very antithesis of agile. Experience gained since 1987 confirms it. At least to me.
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.
Programming is creative works, sure. But there are other creative arts that have existed for thousands of years, why don't we look what they have learned? Painting: The notion of working together on one painting would be absurd to any painter. Sculpting: The same. Composing: Commonly done, with every musician having their own instrument, taking whatever the others have proposed and re-playing it with their modification. Writing: Often done, but writers write whole chapters then send them back and forth for edits until both are happy. So in every other practice they let one artist finish a unit of work, then bounce it around. Nowhere do people interrupt in the middle of a sentence.
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).
I was desperately waiting for you to address the elephant in the room, but you didn't. That is, for pair programming to actually work there has to be somewhat close enough personalitites and thinking styles and really really effective communication in both individuals. Those qualitites aren't miracelously all available in all programmers, especially the communication part. The gap in expertese also has to be small enough to not drown the productivity of the higlhy experienced programmer.
Not my experience at all. You can have very different personalities and experience and to works. Certainly, there are some people that it doesn't work for, but in my experience this is a small minority, maybe 1 in 10.
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.
I guess we sometimes did this unknowingly xD When hopping over to another colleagues desk to clarify something or bounce an idea or mocking a prototype for a few minutes while sipping coffee. Never knew it had a name. I think it's great when it happens naturally.
Biggest advantage is imo that you don't have to do it. That's why the productivity gain is just like 2 people working separately. You don't have to wait for the other person to finish writing the code. You could already think ahead, or even go to your own PC and code something while the other person is busy. Pair programming only has an overhead whenever both developers have the same ideas in which case they could easily temporarily split up the work.
Having done pair programming for over a year at a previous employer and sporadically at various other employers, I can wholeheartedly say I find it debilitating. The problem being one of 'ego' - i.e. those I paired with being too egotistical and "judge-y". Personally I found my skills as a developer got worse rather than better. I prefer "mob" programming as I find people tend to keep their egos in check more, but it's not something I would recommend to do 24/7. As for sharing knowledge, I kind of both agree and disagree. It 'can' be useful for sharing knowledge but only if done right, ensuring that no-one gets left behind, which effectively means going at the pace of the slowest in the pair/mob. This can prove frustrating for those more capable and cause anxiety in those less experienced (especially when paired with those judgemental types!). Also, with mob programming, if someone takes a bathroom break during a session then the entire mob has to stop and wait (so no-one gets left behind right?). In practice this never happens and the rest of the mob would continue without team members being present, who would then miss out on things discussed or progress made and get left behind. Fact is, pair/mob programming is a nice idea, but human nature prevents it from always being practical or efficient. I'd say, go with whatever works for your team... try it... if it works, great! If it doesn't, don't get too hung up on trying to force it. Ditch it and move on.
@@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?
I think "pair programming" is one of those phrases that sounds good to specific types of people. Another example, "we have to give each other positive feedback", and then mandatory "feedback sessions" are installed, and truckloads of cringing ensues. I don't give a hoot about it, it drives me nuts, and is yet another irrelevant thing that eats away at time that could be spent producing. So too with pair programming. It is most often intrusive, energy draining, time consuming, and prevents me from doing my job well. The creative part is best done alone, there's no question about it, then we can talk outlining ideas and review before and after.
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.
@@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.
how do you cope with the fact that there is another person there and you cant focus? or differences in quality of your ideas and fastness? annoying of the other person how is it that theses studies are correct I cannot wrap my head around it. it would drove me mad.
it seems great, unfortunately usually as you explained in the video companies have a very narrow point of view in costs(how many developers, how much time in this feature) vs output(business need) losing with this manteneablity, quality, CoC seems like not as important for organization. will be great in the future to know what is your experience when working with this kind of organizational philosophy.
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!
I’ve become more skeptical when I hear the word “studies” lately. These “studies” can show whatever they are trying to prove. In case of PP study on students, I’ll claim that there are a bunch of students who aren’t good programmers, and when paired with a good programmer the total output will be greater, but in a team where you have well qualified people it will not be so. And if you paired me up with a dummy, I would quickly realize it’s not in my best interest.
Experiments in sociology are always difficult and all are open to similar criticism. I am sure that more rigorous studies could be done, given money and will, so this is all the data that we have, plus the experience of people that have tried it and compared it to other ways of working. I treat studies like these differently to others, primarily the “State of DevOps” reports, which do have a deeper scientific validity in terms of the data collection techniques and statistical analysis of results.
Pair programming has to come with mandatory hours. I really wanted to work at one company that does real estate analytics because because I love real estate. Their recruiter was rather sheepish when explaining what their development team was like. She said that they had hired Pivotal to set up their software development group and Pivotal requires all of their developers to do pair programming and work mandatory hours of 10 AM - 6 PM. She said that she hadn't been able to find anyone who wanted to work under those conditions. I told her that I wouldn't be a good fit on that team either. Maybe Pivotal was being crazy like a fox by doing this. If they impose a regime that no one wants to work under that company would have no choice but to outsource their software development to Pivotal. Think about it. If pair programming, TDD, or any of the other fads being pushed by consultants worked significantly better than other practices then they would be widely adopted because the benefits would be clear.
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.
When I was studying I used to pair program with someone that I felt like was shutting my ideas down. When I suggested making a second class for a problem rather than making a bunch of if statements. He would ask “why do it so complicated?” And keep doing what he was doing. And frankly I had a hard time explaining. For example, how do you justify writing a few lines of code more that solve the problem a bit more generally, if you can just hardcode that thing and say: “we’re not going to change it later anyway” (which oftentimes might be true). For me it unnecessarily restricted what the code could do. I preferred programming alone where I could pursue my clean code standards without being ridiculed for my “complicated” code (that worked, not that it matters).
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
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.
As a developer I can say that pair and mob programming increases quality, throughput and knowledge sharing. I can't see any downsides, we get done quicker, the code is better, team cohesion improves, we get unstuck faster and learn more about the whole stack - instead of working in little silos and being totally lost when some unfamiliar code needs to be touched.
Been doing pair programming for month, I can now see the benefits of it for product delivery. No one is indispensable and newcomer can get to know the code base in a week. A lot has being done and delivered because everyone is productive. But as software engineer who loves programming it is not my cup of tea.
I'm curious how pair programming deal with particularly hard problems. For me, when I'm programming and the problem is a hard one, I'm unable to think on the spot. I have to take a break, digest it for some time, do something else and solution sometimes will pop into my mind. Sometimes I need extreme focus, a "trance" even. Some people call it "flow" Of course it isn't great, because sometimes it is only that one instance of time when I have full grasp of the solution. But couple of time I encountered such problems in my life and I don't really see how we could deal with it while pair programming. I believe Jonathan Blow expressed similar notion in one of the interviews. Sometimes when you are working you are even unable to articulate what you are doing. It is almost like automatic thing or muscle memory.
Thanks for the video, I learned a lot from it! I had to pair program with my friend for the final project of one of my university programming courses, and I had a ton of fun when doing it. We also encountered very few bugs and the final result got the top grade, so my anecdotal experience matches the study results you presented. It's been a decade since that though, and I've pair programmed only a handful of times after that with people I wasn't as comfortable with. I feel like the interpersonal dynamics matter a lot there.
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.
I don't mind saying that I HATE pair programming. For starters, other devs don't appreciate my loud heavy metal music. Moreover, the only situation in which it works is for mentoring weaker programmers. In other instances, it's liable to make you want to kill the other developer...if not actually kill them.
Do you think ping pong TDD is a good way to implement this? The first developer writes a failing test, the second makes it pass and writes another failing test, the first makes it pass and writes another, etc. etc. and then afterward they refactor the code together after writing all the tests that have passed
@@thatoneuser8600 Yes, I've done that in the past, it's a great way to make sure both devs are on the same page. And you do end up with some imaginative unit tests.
Between the video title and the first 48 seconds, I am really confused as to what this video is about. (In case it changes in the future, the title is "You Must Be CRAZY To Do Pair Programming", but the splash screen at 0:43 says "You DON'T Have to be CRAZY to do PAIR PROGRAMMING".)
Yeah... easy to talk about artificial academical studies on students. Now go and apply it in practice and if you care about productivity you'll throw it away the very next day.
I don't usually talk about things that I haven't tried in person, and usually I have tried the alternatives too. In this case I have been practicing pair programming on and off for 20+ years. During that time I have built systems that won awards, and at least one that is regarded as one of the best in its category in the world (a high performance financial exchange). We built some Duke Award winning open source software, and a point of sale system for one of the UK's larger retailers (over 10,000 stores) that is still in daily use 20 years later. So no, you don't "throw it away the very next day".
@@ContinuousDelivery I'm glad that it worked for you but don't you think that would it be such a clear case of improvement - it would be adopted by FAANG as a main practice on a daily basis? Yet, we don't see it happening. These big corporations are usually good at counting money and cutting through the snake oil, that's why you won't see any Agile Coach buffoons there, TDD preachers, etc. I'm sure Pair Programming has it's narrow niche but than it should be presented as such, to not have the credibility of this video evaporated after the first week of real world experience.
@@Krushard No, I don't think that FAANG are necessarily the best at everything. There are lots of practices that I have seen done better, than in FAANG. There are lots of practices that FAANG have adopted from other innovative companies. Pair Programming is, for some reason, culturally difficult to adopt. That is the barrier, not the efficiency or the quality of the work, both of which are not only not problems, but actually, in my experience and from what little data there is, are both better for Pairing.
I started programming computers in Jr High, in an after school, individual self-study course, on a Radio Shack TRS-80 that had a cassette tape drive for storage. I've never stopped coding since. Some time in my 40's.. 30 years later.. I found myself saying, in various circumstances - "My work is always improved by contact with others." But yet still even then I thought the whole idea of pair programming was completely nutzo. In fact, until about 25 minutes ago, I still wouldn't have taken a job that required me to pair program. But now that I've re-heard these very interesting statistics.. I am finding myself rethinking the idea. Imagine it - when I'm driving, I have some poor hapless captive chap sitting right there to explain all my thoughts to. And that poor guy has to sit there and listen! All day long! And, he can share the head banging with me when there's some obstacle or another. Their foreheads can be flattened and their hair can be pulled out right along with mine. And mayhaps neither of us will have lost quite as many hairs and brain cells by the time we've busted through. When I'm the co-pilot, I can sit back and be lazy! Lol. I mean I don't even have to type! I once again have some poor hapless captive chap sitting there whom I get to constantly pummel with all my thoughts. I think as long as the person I'm working with is reasonably congenial, and does a good enough job of hiding his hatred for being chained at the hip with me, I think I might actually like it. I'm pretty introverted, I hate crowds, and parties and stuff, but I don't mind really small groups, and I actually kind of like one-on-one situations. And, when some boss or another comes around wanting to know "how long," there are two of us. So.. I mean.. it might be slightly harder for him to over-thoroughly intimidate both of us. And, if my pair agrees with my wild guess, then I feel slightly less anxious about it. So it actually might be a little less stressful. More productive, And more relaxed! And I might not be quite the incredible hermit that I generally am. People might sort of be almost forced to get to know me. Yeah, I never thought I'd be voluntarily giving up my keyboard for longer then a minute or two, but. I might actually be tempted to give it a try, next time around. With a pair sitting there, I might not find myself taking a little 5 minute break.. and then sort of waking up an hour later in a panic. Ugh.
I'm a lousy typer but a moderate coder, I paired up with a demon typer but less experienced coder. For us for a short burst a couple of weeks this was awesome..
I have tried it and think it fucking sucks ass! When i am the "driver" the other programmer shouts at me to do things differently and i cannot think clearly! When i am on the backseat it frustrates me and i then have the urge to make it myself. It's an idiotic concept and only possible in the over privileged Software "Engineering" industry. Imagine you go to your car mechanic and instead of your usual servicing price of lets say 100 dollar you get a bill of 200 or even 250 dollar, and then the people at the repair shop explain to you: well we use an Xtreme Mechanicing technique called: Pair Mechanicing, instead of one mechanic doing the work, we have two mechanics one is doing the work the other one yells at him. But we have done a study and it says some metrics are higher now, so its absolutely brilliant! So in conclusion pair programming or even mob programming (god help us!) are the newest grifts in the software development industry, an industry with absolutely zero accountability it seems.
Combining "pairing is strongest when the work is new and challenging" and "students are cheaper to experiment on" explains why such positive results were seen. I think for programmers with decades of experience that are set in their ways and are doing something similar to things they have done before, the gain in quality is smaller and style conflicts would be more pronounced, ultimately making it not worth the time cost. Interesting video. Its something to keep in mind.
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 got here due to the clickbaity title, meaning to contradict it - that's obviously not needed. However, there are practical reasons why pair programming can't work well in many teams. For pair programming to work, you need teams where skills and knowledge, and also capacity of effort, is pretty similar. And, even if you don't change pairs every hour, is much more tiresome than everyone working on his own. And it's a cultural thing too - there's a joke that two Finns on the same bus feel like their private space was violated, and I have experienced it first hand that their notion - socially determined - of pair programming is passing the same laptop between two people. Now, Finns may be an extreme example, but many cultures simply are adverse to the physical closeness required by pair programming. So while in theory it's a very useful practice, in practice the conditions to do it productively are often not met. It's useless to employ a technique which increases quality and productivity if people start looking for new jobs - which will absolutely happen if people won't enjoy it. My experience is that pair programming comes naturally when you do it occasionally, in cases where it lends itself excellently to solving the problem of knowledge transfer and learning. Like, for example, when some work needs to be done on code at the interface between two bodies of knowledge.
What has not been covered as an advantage is the time won from instant code review. After pair programming, the code is ready for acceptance and release, because the code has already been seen by two pair of eyes. With regular flow where pull requests waits to be approved, it usually takes 1-3 days longer. Sometimes even more if the reviewer suggests changes or there is a shortage of senior devs. The reason for such difference is the time lag caused by ineffective means of communication - instead of discussing issues over a call immediately, each party waits other to start working after some time X. Furthermore, the regular review flow is disruptive, because developers have to switch back and forth between tasks whether they review it or add requested changes. The disruption often consumes time - developer needs to stash unfinished changes, check out the code and build the development environment again etc... - and has to regain focus again after some time I have seen this from a perspective of a full-stack developer, struggling with time-consuming reviews, and as a DevOps engineer who has been constantly asked to improve the process with additional automation and caching: As a junior full-stack developer, it often took 7 days to get my code released to staging environment. It was not due the amount of requested changes, but merely due the fact that my tasks were not the priority and seniors often had the time to review my tasks 2-3 days after submitting it. By that time, there were already merge conflicts that I had to solve and then request for the review again.... As a DevOps, I have often seen senior devs complaining, that switching between tasks is time consuming for them (e.g. running the code in dev environment consumes a lot of time etc.) and they often request automation and improvements in caching to speed up the work.
I wanted to discuss technology choices with a colleague and he decided to stand up and yell at me in front of the whole office. (I later found out he was taking Methamphetamines.) Sometimes pair programming can't be possible because your fellow programmers are nuts. I think "students" are a poor assessment of viability, because there is no skin in the game. Developers have enhanced insecurities and competitiveness due to the pressures of employment. I have worked in healthy teams that where incredibly productive, but even then there where extremely different personality types and preferences for coding style that in hind sight pair programming would've made us hate each other. My most recent philosophy is to have feature branches with merge requests, but be extremely lenient on my personal preferences... only being considered with the interface being delivered... and not too concerned about how it's done on the inside. Recently I was in a team where none of my code was getting merged over a matter of weeks. This I believe is because my team leaders where threatened by me. So many different ways developers can be disfunctional. It's the sadest part of my career. Good teams are really hard to come by.
Good idea for an organization (esp. if not working remotely), but seems impractical for open source development (cannot collaborate over the web this way, esp. across different time zones with people who have different schedules)
i used to do pair programming when i was still a junior. I learned a lot from my partner and had great fun. Too bad our boss thought it was a waste of time, since one of us isnt typing anything.
I did it once professionally. It was at a horrible company. We did it wrong. It was a disaster and 100% waste of time. We would have been better off having beers at a pub and just talking about code.
If you want people to understand a new codebase ASAP by showing them a high-level overview of it; are there good tools for automating (as much as possible) diagrams/flowcharts of the code base? I'm relatively new to programming and would love to do this for my own projects as a form of documentation.
Are there any pair-programming recommendations for those working remotely, which is most of us in the age of COVID? Even when returning to the office, we can't sit next to each other and share the same workstation.
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.
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.
I was part of a team at a major airline that was asked to start paired programming. I was supplied a keyboard and mouse for a MAC but no computer. I quit.
In nowadays, I believe that technics should be optional for the developers. They should understand that, for instance in complex situation, they can use it.
Two people in front of one computer worked for me as learning teenager or when there is a master and pupil situation, but in day-to-day business when 80% of the code is boring and repetitive coding work, having the passive role is annoying and for the active coder it is annoying to be under constant survaillance so you cannot do your favorite things to shortly escape the tideous work.
Hey Dave (and other colleagues), if a team wants to try pair programming, should we go full time pair programming from the beginning? Our should we begin with couple of hours a day? How long should our experiment with PP last? (for example, a month?)
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!
Honestly, pair programming in lockdown is pretty great. You just share your screen or use one if the ide that feature a multi-user mode, while hanging in a voice call.
It might require some steps prior to pair programming : - teach people how to do non violent code reviews : highlight positive facts as well, listen and ask questions, don't be too judgemental, avoid opinions and ground your proposals... - take care of shy people (they fear judgement by others) : pair them with nice people, let them be navigator to start with to build confidence, be patient :-) Shy and introvert people are different groups with large overlap. Shy people may be difficult to spot when they are not introvert - find cool places : it might be difficult for introverts to focus on the pair interactions in a large and noisy open-plan office, move to a meeting room, have breaks, have discussion while walking ...
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
i am a junior developer and haven't gotten to do any of this at all in my job :( i get the impression my teammates don't have time for it (they are all senior or above).
In my experience, the main efficiency boost is to reduce the time a coder spend getting bored and switching focus to Facebook, Reddit or whatever their chosen skiving site is. In practice, it rarely works unless your pair is well matched, otherwise the more skilled coder charges ahead ignoring the unwanted distraction/spy, and if they switch he gets frustrated and picks the more junior coder's to bits
I quite enjoyed this video - it has given me a bit to think about and possibly suggest to others at work. I think the title of the video is a little confusing though - when I clicked it, I was expecting a video about why pair programming is a negative, not a positive
When I have worked in pairs, the senior developer who can do everything on their own just fine ends up resenting doing work with novice developers that just slow the senior developer down. Because of the way that work was assigned, they end up having to do their own work and the work of the novice. And because the senior developer is respected by management, who don't want to anger a developer that produces alot of valuable output, the pair programming process is not fully supported, and the pairing falls apart. They try to get quality AND timeliness and it can't be done. Its a case of Budget, Schedule, Quality, pick two. If you pick budget [hire junior developer] and quality [pair programming], you lose timeliness.
Measuring self-reported confidence is quite simple: "On a scale, how confident do feel on the task?" Choosing an appropriate scale is the "difficult" part. Thus, the claim "they felt twice as confident" might not be valid.
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.
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!
Oh. My. Dog. I almost cannot believe how COMPLETELY IDENTICAL ALL of the arguments put forth are, to those which I myself highlight each time I try to explain the pros and cons of pair programming to someone. Good to know that I have a backup! 😅 (still, 99% of the time the response I get is "yes, but xyz so that will not work for our team" in order to avoid having to even try it out)
There so many shallow people blabbering nonsense all the time, all of them thinking they are some kinda though leaders. Dave video are like breath of fresh air. Real stuff from someone who knows what he is talking.
“Writes code”? ROFL, that’s what I get to spend about twenty minutes doing after many hours of access requests, escalations, documentation, endless meetings, writing stories for “refinement”, writing my own performance reviews, timekeeping in five different systems, attending team building stuff, etc
Understand the benefits of different pair partnerships
Learn how to introduce pairing as an option for your team, and
Identify anti-patterns and how to avoid them
with my FREE Pair Programming Guide, which you can get here ➡ www.subscribepage.com/cd-pair-guide
I did pair programming in early 2000's for 5 years and I will avoid any job that does pair programming as a required practice for all development. Its great for mentoring and on occasion but nearly drove me from the profession when I had to do it all the time. We had several training sessions by Bob Martin from Object Mentor... so we did it close to "right". Bob even admitted that they didn't pair program much at Object Mentor (at the time I asked).
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.
I usually agree entirely, but have mixed experiences with pair programming.
I've had both positive and negative experiences, but more negative than positive. I understand that this may be highlighting a failing in myself, but I don't think that's necessarily the case.
I'm quite an experienced developer, but in my very early professional years I was something of a maverick, and I came across as arrogant. Learning to work with others of various skill levels was probably a more important lesson for me than any other that I've learned in programming. Unfortunately, not all developers learn this same lesson.
I've paired with other programmers that have a heavy ego, and are quite inflexible in the navigator role. I find this hideously irritating and have done an even share of biting my tongue vs standing my ground with them. I've also worked with novices that have the same maverick attitude that I once did, which is no less irritating. Ultimately, when pairing like this, I find it too often becomes adversarial. I might come away with code written to appease the pair, or a dissatisfaction with the result, and I generally dread doing the same again tomorrow.
This is not to say that ALL pair experiences have gone this way, and I've had several which worked quite well.
What HAS worked for me is teaming with another developer on a feature. A sub-team of two solo developers makes for a very interesting dynamic. Generally, you both get on and write your own end of the feature, but when either gets stuck they can consult with the other, which is far easier. If one developer has asked another for help, there is already an implied stance on who is asking for help, and who is giving. You may still disagree, but it's more rare that you do, and it's no skin to be asked for advice not taken. Further more, you're likely to step into actual paired programming when the situation calls for it, and without the adversarial environment. i.e. I'm now willingly pairing, rather than being asked to do so in some mandated rotation. This comes with all of the same benefits, such as the pair demonstrating how they work with the tools, debuggers, keyboard hot-keys etc.
Pair-Team Anecdote: Around 15 years ago, I worked with a former Microsoft developer that was an absolute expert with the .NET framework. We were tasked with making .NET managed, and native code communicate with each other (IPC). When we first discussed this, I suggested using a windows API message WM_USER+ but the other developer had no knowledge of the windows message loop. I was a little taken aback at first to hear this from someone that had worked at Microsoft, until I realized that the .NET framework generally shields you from having to know about the workings underneath. I explained and demonstrated the loop, helped to look up win32 API bindings to create the necessary .NET invoke calls, and then spent two weeks back and forth with the other developer, sharing ideas which detailed the communication protocol and so on. What worked was that we were each the subject experts for our own piece of the code, but working towards the same goal. We could share solutions to memory management when passing between managed and unmanaged code, knowing that we could each rely on the other for the knowledge we needed to keep working.
So, with no statistics but only personal experience to back this assertion. I would suggest that teams breaking into sub-teams of two developers is a far more productive solution, and, management can be told that they're still getting the work of two to put into their spreadsheets.
This channel is lit 🔥 it gives us a lot of engineering gems 💎 that are rare to find these days specially as self taught developers
I loved the point you made about this helping LEARNING, this is an interesting framing for this. I'm going to try this with NON-programming tasks with some of my students and see if they can improve.
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.
At a minimum, every time you commit there are twice as many developers intimately familiar with the code if it needs maintenance.
@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.
Me and a buddy did that in 1983 doing assembly on the zx81. Its amazing how different our styles are even just using the same dozen op codes. we still do as a hobby lol. Why rotate so much? I get if for homogeneity, and levelling up the team and all that but there's frictional losses and too hard to sustain IMO. I'd rather do through feature completion, then rotate (social factors)
I have enjoyed using pair programming a few times but most of the time it completely drains my energy, my creativity goes down and everything becomes rushed. Not sure about the issue, through.
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.
I don't like pair programming. The systems that I work on require a ton of context to be loaded into my head before I can begin mucking with the code. Having someone look over my shoulder and comment on everything I do tends to cause the context to leave my head. Maybe it's OK on a new project.
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.
I always found pair programming to be good in principle, but terrible in practice. It breaks the flow of code far too much and leads to worse code in my experience.
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...
I have found a number of caveats. Many developers are introverts by nature, which doesn't mean are anti-social, but constant social interaction can be draining to them over long periods of time. It can also lead to analysis paralysis. Very good tool for mentoring new developers though.
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.
Pair programming? How about pair team leads? Or pair managers? Where to start. Why is coding being conflated with teaching? Why is disaster mitigation being leveraged with pair programming?
How about a pair being completely mismatched in skill set? Or when someone wants to code in complete silence?
The sure path to insanity is to watch someone hunt and peck at a keyboard, trying to remember the key combination
to delete the next three words and append a comma.
I like your presentations, and this was well presented, but I couldn’t disagree with you more.
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.
While pair programming is great for sharing knowledge I have a hard time accepting the productivity claims. The mental state known as "flow" cannot be achieved when working in a pair. This state of intense uninterrupted concentration maintained for several hours is both extremely productive and also pleasurable as a programmer.
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've been really struggling with this in DevOps for a long time - everywhere I go, I end up on a "team" of individuals, working on disparate work streams, with very little day-to-day collaboration.
Sure, for simple admin stuff, this is fine, but when you have to do something complex / implement something new, I often need to spend much longer on knowledge transfer (partly because of the junior nature of my colleagues).
This is something I'm going to take a much harder line on as I think it really would be a Silver Bullet for so much; in the DevOps context, this would mean more like one person doing, the other documenting, which is at least a line I can try to placate the bean-counters...
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 😖
I ended up quitting one job because of pair programming. I am unable to maintain focus and concentration consistently over an 8-hour workday, and so it was difficult to match up with my partner. In addition, I'm quite introverted and found it draining to interact socially continuously over that period. I would often come home exhausted and just be unwilling to do anything after work, which was toxic for my social life.
I wouldn't mind pairing once or twice a week for just a few hours at a time. In fact, that was how my friends and I often got through the barrage of homework assignments we were given in college. For me, I am more productive, mostly due to feeling the social pressure of needing to contribute to solving the problem at hand in a timely fashion. Working in a team has its own way of motivating attention. The way it is practiced in Xtreme Programming is intolerable to me, however, and I would never join a company that practiced it daily. The dream, for me, is a quiet office where I get about 3-4 hours of uninterrupted, focused programming done per day.
So yes, I agree that pair programming works. It's just that I would quit due to having to work my brain so much harder every day. Since senior engineers are in high demand, I get to pick my work environment. Those who are more extroverted should definitely give it a shot - they'll probably find it enjoyable. However, those types tend to self-select out of engineering and drift towards management.
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
I loved this, and I always loved the idea of pair programming. However, in practice, both as a developer and as a tech lead, I've never managed to make it work on a daily basis like you recommend. I used it sparingly for onboarding and for when somebody is stuck on a problem.
I'm super enticed by your experience, though. I'd love to see a follow up video which could get into the nitty-gritty of how to actually pull this off.
Been forced to do this at a new company for 3 weeks now and about to jump ship. No freedom, someone talking in your ear constantly. Doing this 8 hours a day every day is an atrocious idea. On a case by case basis; personally I’m about to scream and about to quit. 20 years experience and I’ve never had a more ridiculous experience ever. I don’t care about the productivity and code quality benefits, none of that matters if you’re not taking into account the psychological health of your developers.
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...
I find it utterly intolerable. It almost completely destroys concentration and creativity. Furthermore, it sucks all of the joy out of developing software and the pride of accomplishment. The only time I have ever seen it be effective is when tutoring another programmer or when assisting another one.
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.
it's a living nightmare for people with social anxiety, btw.
You may find my post on "Pair Programming for Introverts" interesting: www.davefarley.net/?p=267
Pair Programming: loved by managers; hated by programmers.
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.
Can you link the studies that point the performance and quality of work done in pairs?
About a year and a half back I went to a Global Game Jam.
I do not know anything about making games. For some reason I ended up with a couple of senior guys from the university.
I knew some Java, but we used Unity, which uses C#.
One of the seniors didn't code anything, just guided me. I ended up doing the movement for our player.
The small game was pretty much actually. I still remember that GGJ fondly.
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."
freakCodeCamp Presents:
THE PAIR PROGRAMMING COMEDY PODCAST
STARING WILL AND BILL
Will: You idiot! I said type "script" not typescript
Bill: okay, typescript or javascript, whatever you say boss
Will: Now declare a variable- you know how to declare a variable, don't you?
Bill: I know how to do a backside arial, I've never heard of an "eclair arial"
Will: This is a computer, not a skateboard, you idiot...
1) It might work well for juniors but not so much for seniors. 2) The studies are based on statistics, thus peer programming isn't for everyone. 3) Nothing can't beat a good methodology when it comes to learning. 4) Forcing people to work in pairs and taking into consideration the job rotation in the sector is like practising tango and changing dance partner very often; by the time you're in tune with each other, you need to start over. 5) Programmers aren't "dance partners", no one signed for that kind of stuff when joined IT. Stop seeing people as just resources to be squeezed in order to get more productivity. 6) People need time and space to research and explore so too boost their creativity. 7) Make it optional for those who want to work like that, but never ever force it upon people.
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 :)
Having worked on a number of agile and XP programming projects, all of which were disastrous, I have concluded that Agile and its off-shoots is nothing more than a cult, which has provided an opportunity for some people (the Scrum masters etc.) to make a lot of money, acting as the high priests of their lowly, sheep-like flock. I've realised that it works for people of a certain personality type (happy to follow) or for inexperienced engineers (happy to be on a team learning from more experienced people - it's good in this respect), but for very experienced engineers, it's constraining and frustrating.
We have just inherited a 6 year overdue project from a large provider of critical national infrastructure. They had sixty developers working on the project in one form or another. We are putting 10 people on the project. *That's* how you do Agile (in my experience). Fred Brooks was right. Teams should be small, not large. When a team becomes too large, it becomes the very antithesis of agile. Experience gained since 1987 confirms it. At least to me.
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.
Programming is creative works, sure. But there are other creative arts that have existed for thousands of years, why don't we look what they have learned?
Painting: The notion of working together on one painting would be absurd to any painter.
Sculpting: The same.
Composing: Commonly done, with every musician having their own instrument, taking whatever the others have proposed and re-playing it with their modification.
Writing: Often done, but writers write whole chapters then send them back and forth for edits until both are happy.
So in every other practice they let one artist finish a unit of work, then bounce it around. Nowhere do people interrupt in the middle of a sentence.
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).
I was desperately waiting for you to address the elephant in the room, but you didn't. That is, for pair programming to actually work there has to be somewhat close enough personalitites and thinking styles and really really effective communication in both individuals. Those qualitites aren't miracelously all available in all programmers, especially the communication part. The gap in expertese also has to be small enough to not drown the productivity of the higlhy experienced programmer.
Not my experience at all. You can have very different personalities and experience and to works. Certainly, there are some people that it doesn't work for, but in my experience this is a small minority, maybe 1 in 10.
How would I find the studies that show Pair Programming is beneficial?
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
yeah okay, you got me on this one. liked and subscribed, greetings from germany
grüße
Welcome aboard!
Thanks for sharing your experience with us!
You really seam to know what you're taking about! Great and encouraging speech!
I guess we sometimes did this unknowingly xD When hopping over to another colleagues desk to clarify something or bounce an idea or mocking a prototype for a few minutes while sipping coffee. Never knew it had a name. I think it's great when it happens naturally.
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.
Pair programming is HELL to any introvert programmer. It sucks harder than a NILFISK.
Biggest advantage is imo that you don't have to do it. That's why the productivity gain is just like 2 people working separately. You don't have to wait for the other person to finish writing the code. You could already think ahead, or even go to your own PC and code something while the other person is busy. Pair programming only has an overhead whenever both developers have the same ideas in which case they could easily temporarily split up the work.
Having done pair programming for over a year at a previous employer and sporadically at various other employers, I can wholeheartedly say I find it debilitating. The problem being one of 'ego' - i.e. those I paired with being too egotistical and "judge-y". Personally I found my skills as a developer got worse rather than better. I prefer "mob" programming as I find people tend to keep their egos in check more, but it's not something I would recommend to do 24/7.
As for sharing knowledge, I kind of both agree and disagree. It 'can' be useful for sharing knowledge but only if done right, ensuring that no-one gets left behind, which effectively means going at the pace of the slowest in the pair/mob. This can prove frustrating for those more capable and cause anxiety in those less experienced (especially when paired with those judgemental types!).
Also, with mob programming, if someone takes a bathroom break during a session then the entire mob has to stop and wait (so no-one gets left behind right?). In practice this never happens and the rest of the mob would continue without team members being present, who would then miss out on things discussed or progress made and get left behind.
Fact is, pair/mob programming is a nice idea, but human nature prevents it from always being practical or efficient. I'd say, go with whatever works for your team... try it... if it works, great! If it doesn't, don't get too hung up on trying to force it. Ditch it and move on.
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?
@ContinuousDelivery is there a list of the studies you mention somewhere? Would be great :)
I think "pair programming" is one of those phrases that sounds good to specific types of people. Another example, "we have to give each other positive feedback", and then mandatory "feedback sessions" are installed, and truckloads of cringing ensues. I don't give a hoot about it, it drives me nuts, and is yet another irrelevant thing that eats away at time that could be spent producing. So too with pair programming. It is most often intrusive, energy draining, time consuming, and prevents me from doing my job well.
The creative part is best done alone, there's no question about it, then we can talk outlining ideas and review before and after.
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.
Pair programming is not always useful, but! Pair programming is completely underrated!
For me pair programming (when working on my private projects) is mostly a really great fun.
how do you cope with the fact that there is another person there and you cant focus? or differences in quality of your ideas and fastness? annoying of the other person how is it that theses studies are correct I cannot wrap my head around it. it would drove me mad.
it seems great, unfortunately usually as you explained in the video companies have a very narrow point of view in costs(how many developers, how much time in this feature) vs output(business need) losing with this manteneablity, quality, CoC seems like not as important for organization. will be great in the future to know what is your experience when working with this kind of organizational philosophy.
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!
Every time you say "in another study" I expect to see your sources. None given. Otherwise your claim is baseless.
He expects you to Google it yourself, you spoodfed child.
@@kaimiddleton1811 I got a few results on Google Scholar. It’s really not that hard.
I’ve become more skeptical when I hear the word “studies” lately. These “studies” can show whatever they are trying to prove. In case of PP study on students, I’ll claim that there are a bunch of students who aren’t good programmers, and when paired with a good programmer the total output will be greater, but in a team where you have well qualified people it will not be so. And if you paired me up with a dummy, I would quickly realize it’s not in my best interest.
Experiments in sociology are always difficult and all are open to similar criticism. I am sure that more rigorous studies could be done, given money and will, so this is all the data that we have, plus the experience of people that have tried it and compared it to other ways of working. I treat studies like these differently to others, primarily the “State of DevOps” reports, which do have a deeper scientific validity in terms of the data collection techniques and statistical analysis of results.
Pair programming has to come with mandatory hours.
I really wanted to work at one company that does real estate analytics because because I love real estate. Their recruiter was rather sheepish when explaining what their development team was like. She said that they had hired Pivotal to set up their software development group and Pivotal requires all of their developers to do pair programming and work mandatory hours of 10 AM - 6 PM. She said that she hadn't been able to find anyone who wanted to work under those conditions. I told her that I wouldn't be a good fit on that team either.
Maybe Pivotal was being crazy like a fox by doing this. If they impose a regime that no one wants to work under that company would have no choice but to outsource their software development to Pivotal.
Think about it. If pair programming, TDD, or any of the other fads being pushed by consultants worked significantly better than other practices then they would be widely adopted because the benefits would be clear.
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.
It's a great process for shit developers, to be sure. What a nightmarish work environment you propose.
Well if that is true, it means that shit developers can create world-class code with they do this 😁😎
And of course, this looks like 9 women having a baby in one month. The math makes sense …
@Abhijit Bhattacharya Picasso, Michelangelo, Dali and da Vinci have entered the chat.
Maths is a mess and has little to do with real world workings.
When I was studying I used to pair program with someone that I felt like was shutting my ideas down. When I suggested making a second class for a problem rather than making a bunch of if statements. He would ask “why do it so complicated?” And keep doing what he was doing.
And frankly I had a hard time explaining.
For example, how do you justify writing a few lines of code more that solve the problem a bit more generally, if you can just hardcode that thing and say: “we’re not going to change it later anyway” (which oftentimes might be true).
For me it unnecessarily restricted what the code could do.
I preferred programming alone where I could pursue my clean code standards without being ridiculed for my “complicated” code (that worked, not that it matters).
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
This sounds like hell to me as an introvert. I think I will quit being a programmer if pair programming is prevalent.
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.
As a developer I can say that pair and mob programming increases quality, throughput and knowledge sharing. I can't see any downsides, we get done quicker, the code is better, team cohesion improves, we get unstuck faster and learn more about the whole stack - instead of working in little silos and being totally lost when some unfamiliar code needs to be touched.
Well for me personally this really exhausting. I can only deal with a certain amount of human Interaction per day.
Been doing pair programming for month, I can now see the benefits of it for product delivery. No one is indispensable and newcomer can get to know the code base in a week. A lot has being done and delivered because everyone is productive. But as software engineer who loves programming it is not my cup of tea.
but how do you handle moments where one of you spends 2 hours researching how to solve the problem?
Spend the 2 hours to solve the problem! Usually do it together as a pair, bouncing ideas around.
I'm curious how pair programming deal with particularly hard problems.
For me, when I'm programming and the problem is a hard one, I'm unable to think on the spot. I have to take a break, digest it for some time, do something else and solution sometimes will pop into my mind. Sometimes I need extreme focus, a "trance" even. Some people call it "flow"
Of course it isn't great, because sometimes it is only that one instance of time when I have full grasp of the solution. But couple of time I encountered such problems in my life and I don't really see how we could deal with it while pair programming.
I believe Jonathan Blow expressed similar notion in one of the interviews. Sometimes when you are working you are even unable to articulate what you are doing. It is almost like automatic thing or muscle memory.
The only thing which I find even more useful than Pair Programming is (Remote) Mob Programming
"Students are cheaper to experiment on" gave me a hearty chuckle.
Thanks for the video, I learned a lot from it! I had to pair program with my friend for the final project of one of my university programming courses, and I had a ton of fun when doing it. We also encountered very few bugs and the final result got the top grade, so my anecdotal experience matches the study results you presented. It's been a decade since that though, and I've pair programmed only a handful of times after that with people I wasn't as comfortable with. I feel like the interpersonal dynamics matter a lot there.
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.
It works with students not for professionals competing to get that shiny recognition!
I think that depends on where the "professionals" work. It certainly is employed, and does work, in some professional settings.
I don't mind saying that I HATE pair programming. For starters, other devs don't appreciate my loud heavy metal music. Moreover, the only situation in which it works is for mentoring weaker programmers. In other instances, it's liable to make you want to kill the other developer...if not actually kill them.
Pair Programming fails every time when Dave's point at16:32 is not upheld. One dominant developer will put the other to sleep.
Do you think ping pong TDD is a good way to implement this? The first developer writes a failing test, the second makes it pass and writes another failing test, the first makes it pass and writes another, etc. etc. and then afterward they refactor the code together after writing all the tests that have passed
@@thatoneuser8600 Yes, I've done that in the past, it's a great way to make sure both devs are on the same page. And you do end up with some imaginative unit tests.
Between the video title and the first 48 seconds, I am really confused as to what this video is about. (In case it changes in the future, the title is "You Must Be CRAZY To Do Pair Programming", but the splash screen at 0:43 says "You DON'T Have to be CRAZY to do PAIR PROGRAMMING".)
Yeah... easy to talk about artificial academical studies on students. Now go and apply it in practice and if you care about productivity you'll throw it away the very next day.
I don't usually talk about things that I haven't tried in person, and usually I have tried the alternatives too. In this case I have been practicing pair programming on and off for 20+ years.
During that time I have built systems that won awards, and at least one that is regarded as one of the best in its category in the world (a high performance financial exchange). We built some Duke Award winning open source software, and a point of sale system for one of the UK's larger retailers (over 10,000 stores) that is still in daily use 20 years later.
So no, you don't "throw it away the very next day".
@@ContinuousDelivery I'm glad that it worked for you but don't you think that would it be such a clear case of improvement - it would be adopted by FAANG as a main practice on a daily basis? Yet, we don't see it happening. These big corporations are usually good at counting money and cutting through the snake oil, that's why you won't see any Agile Coach buffoons there, TDD preachers, etc. I'm sure Pair Programming has it's narrow niche but than it should be presented as such, to not have the credibility of this video evaporated after the first week of real world experience.
@@Krushard No, I don't think that FAANG are necessarily the best at everything. There are lots of practices that I have seen done better, than in FAANG. There are lots of practices that FAANG have adopted from other innovative companies. Pair Programming is, for some reason, culturally difficult to adopt. That is the barrier, not the efficiency or the quality of the work, both of which are not only not problems, but actually, in my experience and from what little data there is, are both better for Pairing.
I started programming computers in Jr High, in an after school, individual self-study course, on a Radio Shack TRS-80 that had a cassette tape drive for storage. I've never stopped coding since.
Some time in my 40's.. 30 years later.. I found myself saying, in various circumstances - "My work is always improved by contact with others."
But yet still even then I thought the whole idea of pair programming was completely nutzo. In fact, until about 25 minutes ago, I still wouldn't have taken a job that required me to pair program.
But now that I've re-heard these very interesting statistics.. I am finding myself rethinking the idea. Imagine it - when I'm driving, I have some poor hapless captive chap sitting right there to explain all my thoughts to. And that poor guy has to sit there and listen! All day long! And, he can share the head banging with me when there's some obstacle or another. Their foreheads can be flattened and their hair can be pulled out right along with mine. And mayhaps neither of us will have lost quite as many hairs and brain cells by the time we've busted through. When I'm the co-pilot, I can sit back and be lazy! Lol. I mean I don't even have to type! I once again have some poor hapless captive chap sitting there whom I get to constantly pummel with all my thoughts. I think as long as the person I'm working with is reasonably congenial, and does a good enough job of hiding his hatred for being chained at the hip with me, I think I might actually like it. I'm pretty introverted, I hate crowds, and parties and stuff, but I don't mind really small groups, and I actually kind of like one-on-one situations. And, when some boss or another comes around wanting to know "how long," there are two of us. So.. I mean.. it might be slightly harder for him to over-thoroughly intimidate both of us. And, if my pair agrees with my wild guess, then I feel slightly less anxious about it. So it actually might be a little less stressful. More productive, And more relaxed! And I might not be quite the incredible hermit that I generally am. People might sort of be almost forced to get to know me. Yeah, I never thought I'd be voluntarily giving up my keyboard for longer then a minute or two, but. I might actually be tempted to give it a try, next time around. With a pair sitting there, I might not find myself taking a little 5 minute break.. and then sort of waking up an hour later in a panic. Ugh.
I'm a lousy typer but a moderate coder, I paired up with a demon typer but less experienced coder. For us for a short burst a couple of weeks this was awesome..
I have tried it and think it fucking sucks ass! When i am the "driver" the other programmer shouts at me to do things differently and i cannot think clearly! When i am on the backseat it frustrates me and i then have the urge to make it myself.
It's an idiotic concept and only possible in the over privileged Software "Engineering" industry.
Imagine you go to your car mechanic and instead of your usual servicing price of lets say 100 dollar you get a bill of 200 or even 250 dollar, and then the people at the repair shop explain to you: well we use an Xtreme Mechanicing technique called: Pair Mechanicing, instead of one mechanic doing the work, we have two mechanics one is doing the work the other one yells at him. But we have done a study and it says some metrics are higher now, so its absolutely brilliant!
So in conclusion pair programming or even mob programming (god help us!) are the newest grifts in the software development industry, an industry with absolutely zero accountability it seems.
Another Elephant: My ideas are better than yours and I have to control you constantly. I want you to write THIS code NOW!
Combining "pairing is strongest when the work is new and challenging" and "students are cheaper to experiment on" explains why such positive results were seen. I think for programmers with decades of experience that are set in their ways and are doing something similar to things they have done before, the gain in quality is smaller and style conflicts would be more pronounced, ultimately making it not worth the time cost. Interesting video. Its something to keep in mind.
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 got here due to the clickbaity title, meaning to contradict it - that's obviously not needed. However, there are practical reasons why pair programming can't work well in many teams. For pair programming to work, you need teams where skills and knowledge, and also capacity of effort, is pretty similar. And, even if you don't change pairs every hour, is much more tiresome than everyone working on his own.
And it's a cultural thing too - there's a joke that two Finns on the same bus feel like their private space was violated, and I have experienced it first hand that their notion - socially determined - of pair programming is passing the same laptop between two people. Now, Finns may be an extreme example, but many cultures simply are adverse to the physical closeness required by pair programming.
So while in theory it's a very useful practice, in practice the conditions to do it productively are often not met. It's useless to employ a technique which increases quality and productivity if people start looking for new jobs - which will absolutely happen if people won't enjoy it.
My experience is that pair programming comes naturally when you do it occasionally, in cases where it lends itself excellently to solving the problem of knowledge transfer and learning. Like, for example, when some work needs to be done on code at the interface between two bodies of knowledge.
What has not been covered as an advantage is the time won from instant code review. After pair programming, the code is ready for acceptance and release, because the code has already been seen by two pair of eyes. With regular flow where pull requests waits to be approved, it usually takes 1-3 days longer. Sometimes even more if the reviewer suggests changes or there is a shortage of senior devs.
The reason for such difference is the time lag caused by ineffective means of communication - instead of discussing issues over a call immediately, each party waits other to start working after some time X. Furthermore, the regular review flow is disruptive, because developers have to switch back and forth between tasks whether they review it or add requested changes. The disruption often consumes time - developer needs to stash unfinished changes, check out the code and build the development environment again etc... - and has to regain focus again after some time
I have seen this from a perspective of a full-stack developer, struggling with time-consuming reviews, and as a DevOps engineer who has been constantly asked to improve the process with additional automation and caching:
As a junior full-stack developer, it often took 7 days to get my code released to staging environment. It was not due the amount of requested changes, but merely due the fact that my tasks were not the priority and seniors often had the time to review my tasks 2-3 days after submitting it. By that time, there were already merge conflicts that I had to solve and then request for the review again....
As a DevOps, I have often seen senior devs complaining, that switching between tasks is time consuming for them (e.g. running the code in dev environment consumes a lot of time etc.) and they often request automation and improvements in caching to speed up the work.
I wanted to discuss technology choices with a colleague and he decided to stand up and yell at me in front of the whole office. (I later found out he was taking Methamphetamines.) Sometimes pair programming can't be possible because your fellow programmers are nuts.
I think "students" are a poor assessment of viability, because there is no skin in the game. Developers have enhanced insecurities and competitiveness due to the pressures of employment.
I have worked in healthy teams that where incredibly productive, but even then there where extremely different personality types and preferences for coding style that in hind sight pair programming would've made us hate each other.
My most recent philosophy is to have feature branches with merge requests, but be extremely lenient on my personal preferences... only being considered with the interface being delivered... and not too concerned about how it's done on the inside.
Recently I was in a team where none of my code was getting merged over a matter of weeks. This I believe is because my team leaders where threatened by me.
So many different ways developers can be disfunctional. It's the sadest part of my career. Good teams are really hard to come by.
Good idea for an organization (esp. if not working remotely), but seems impractical for open source development (cannot collaborate over the web this way, esp. across different time zones with people who have different schedules)
i used to do pair programming when i was still a junior. I learned a lot from my partner and had great fun. Too bad our boss thought it was a waste of time, since one of us isnt typing anything.
I did it once professionally. It was at a horrible company. We did it wrong. It was a disaster and 100% waste of time. We would have been better off having beers at a pub and just talking about code.
If you want people to understand a new codebase ASAP by showing them a high-level overview of it; are there good tools for automating (as much as possible) diagrams/flowcharts of the code base? I'm relatively new to programming and would love to do this for my own projects as a form of documentation.
I’d suggest research, and if it doesn’t exist, build it :-).
Hello. This is nexovec. He doesn't like drag, so he minimizes it. Nexovec is a happy programmer. Be like nexovec.
Are there any pair-programming recommendations for those working remotely, which is most of us in the age of COVID? Even when returning to the office, we can't sit next to each other and share the same workstation.
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.
I was part of a team at a major airline that was asked to start paired programming. I was supplied a keyboard and mouse for a MAC but no computer. I quit.
In nowadays, I believe that technics should be optional for the developers. They should understand that, for instance in complex situation, they can use it.
Two people in front of one computer worked for me as learning teenager or when there is a master and pupil situation, but in day-to-day business when 80% of the code is boring and repetitive coding work, having the passive role is annoying and for the active coder it is annoying to be under constant survaillance so you cannot do your favorite things to shortly escape the tideous work.
It is far better to first have the design and subsequently the algorithm reviewed before coding.
Hey Dave (and other colleagues), if a team wants to try pair programming, should we go full time pair programming from the beginning? Our should we begin with couple of hours a day?
How long should our experiment with PP last? (for example, a month?)
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!
Honestly, pair programming in lockdown is pretty great. You just share your screen or use one if the ide that feature a multi-user mode, while hanging in a voice call.
How about au pair programming
Depends on how "programmable" your Au pair is :)
It might require some steps prior to pair programming :
- teach people how to do non violent code reviews : highlight positive facts as well, listen and ask questions, don't be too judgemental, avoid opinions and ground your proposals...
- take care of shy people (they fear judgement by others) : pair them with nice people, let them be navigator to start with to build confidence, be patient :-)
Shy and introvert people are different groups with large overlap. Shy people may be difficult to spot when they are not introvert
- find cool places : it might be difficult for introverts to focus on the pair interactions in a large and noisy open-plan office, move to a meeting room, have breaks, have discussion while walking ...
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
Pressures me to make my code explainable => Simpler & More Maintainable.
i am a junior developer and haven't gotten to do any of this at all in my job :( i get the impression my teammates don't have time for it (they are all senior or above).
07:00 Fuck!!! I do hate those pointy Hair bosses
!!! who put them there?!
okay but how do you do a power nap or a fridge blitzkrieg in pair programming?
In my experience, the main efficiency boost is to reduce the time a coder spend getting bored and switching focus to Facebook, Reddit or whatever their chosen skiving site is.
In practice, it rarely works unless your pair is well matched, otherwise the more skilled coder charges ahead ignoring the unwanted distraction/spy, and if they switch he gets frustrated and picks the more junior coder's to bits
OMG once you get used to it Pair Programming is better than sex with a hot woman!
Great analysis and great explanations. Thank you so much!
Glad it was helpful!
I quite enjoyed this video - it has given me a bit to think about and possibly suggest to others at work.
I think the title of the video is a little confusing though - when I clicked it, I was expecting a video about why pair programming is a negative, not a positive
Yeah, it's a "clickbaity" title, the only thing I didn't like about the video.
When I have worked in pairs, the senior developer who can do everything on their own just fine ends up resenting doing work with novice developers that just slow the senior developer down. Because of the way that work was assigned, they end up having to do their own work and the work of the novice. And because the senior developer is respected by management, who don't want to anger a developer that produces alot of valuable output, the pair programming process is not fully supported, and the pairing falls apart. They try to get quality AND timeliness and it can't be done. Its a case of Budget, Schedule, Quality, pick two. If you pick budget [hire junior developer] and quality [pair programming], you lose timeliness.
@@andrealaforgia5066 Fair point, thanks for it.
Measuring self-reported confidence is quite simple: "On a scale, how confident do feel on the task?" Choosing an appropriate scale is the "difficult" part. Thus, the claim "they felt twice as confident" might not be valid.
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.
This works for beginners or students
Pair Programming with formatting nit-pickers is annoying.
Thanks for the in depth explanation. How do you think will it work when the pair don't physically sit together?
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!
Oh. My. Dog. I almost cannot believe how COMPLETELY IDENTICAL ALL of the arguments put forth are, to those which I myself highlight each time I try to explain the pros and cons of pair programming to someone. Good to know that I have a backup! 😅
(still, 99% of the time the response I get is "yes, but xyz so that will not work for our team" in order to avoid having to even try it out)
1. More lighting on your body.
2. Please do explicitly enumerate the references in the description.
For one on a team that can become extremely siloed, this is an attractive option. I look forward to trying it out
If you would like a helpful guide on Pair Programming: www.subscribepage.com/cd-pair-guide
There so many shallow people blabbering nonsense all the time, all of them thinking they are some kinda though leaders.
Dave video are like breath of fresh air.
Real stuff from someone who knows what he is talking.
Thank you 😁
That animated background is cool!
“Writes code”? ROFL, that’s what I get to spend about twenty minutes doing after many hours of access requests, escalations, documentation, endless meetings, writing stories for “refinement”, writing my own performance reviews, timekeeping in five different systems, attending team building stuff, etc
most extreme? Mob programing is like hold my beer haha
Mob programming where CEO write code and everyone finds mistake in his code