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).

@VideoGameBoxReviews

8 ай бұрын

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.

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.

@crushingbelial

Жыл бұрын

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

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).

@mharley3791

Жыл бұрын

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 channel is lit 🔥 it gives us a lot of engineering gems 💎 that are rare to find these days specially as self taught developers

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.

@ContinuousDelivery

3 жыл бұрын

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.

@thaianle4623

3 жыл бұрын

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.

@chudchadanstud

3 жыл бұрын

@@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.

@Protocultor

3 жыл бұрын

@@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.

@m.x.

3 жыл бұрын

@@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.

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.

@ContinuousDelivery

3 жыл бұрын

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.

@andrewadkins8440

3 жыл бұрын

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.

@_winston_smith_

3 жыл бұрын

@@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 .

@andrewadkins8440

3 жыл бұрын

@@_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.

@pappont

2 жыл бұрын

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

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)

At a minimum, every time you commit there are twice as many developers intimately familiar with the code if it needs maintenance.

@murraynatkie7490

3 жыл бұрын

@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. ;-)

@BittermanAndy

2 жыл бұрын

@@mwwhited bingo.

@miledavitkovski1343

2 жыл бұрын

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.

@alexhaigh9575

Жыл бұрын

@@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.

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.

@ContinuousDelivery

3 жыл бұрын

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.

@georgeonearth

3 жыл бұрын

​@@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.

@nlac73

2 жыл бұрын

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 :)

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.

@georgeonearth

3 жыл бұрын

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.

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...

@seanogorman6940

Жыл бұрын

100 percent

@manishm9478

8 ай бұрын

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 😖

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.

@ddanielsandberg

3 жыл бұрын

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

I 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.

Thanks for sharing your experience with us! You really seam to know what you're taking about! Great and encouraging speech!

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.

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.

@PatrikKron

3 жыл бұрын

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.

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.

@_Mentat

3 жыл бұрын

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".

@NotMarkKnopfler

3 жыл бұрын

@@_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.

@ajward137

3 жыл бұрын

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.

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.

@deanschulze3129

3 жыл бұрын

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.

@user-jn4sw3iw4h

3 жыл бұрын

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.

@PatrikKron

3 жыл бұрын

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.

@deanschulze3129

3 жыл бұрын

@@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 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.

@Omnifarious0

3 жыл бұрын

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.

@edwardcullen1739

3 жыл бұрын

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.

@Voidsway

3 жыл бұрын

@@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.

@Golnarth

3 жыл бұрын

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.

@a0flj0

3 жыл бұрын

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.

Great episode and a really good and helpful look on pair programming from different sides. Oh, and I just loved you depicting experts with images of Grace Hopper and Margaret Hamilton! Awesome move! Cheers, Harald

@ContinuousDelivery

2 жыл бұрын

Glad you enjoyed it!

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.

@mbartelsm

3 жыл бұрын

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.

@jyrinx

2 жыл бұрын

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

Great analysis and great explanations. Thank you so much!

@ContinuousDelivery

3 жыл бұрын

Glad it was helpful!

I saw this video a while back and while interested in the concept I didn't have the chance to test this out. I'm currently in a practice module in my Univerity and could test it and all the points of the video hold true atm. I'm positively suprised

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.

@ContinuousDelivery

3 жыл бұрын

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

3 жыл бұрын

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

@BittermanAndy

3 жыл бұрын

@@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.

Loved the video . Even if I don't work in a proper development project. I know how it's going to help, it's the ultimate level of collaboration. In this WFH situation, I always try to connect with my teammate when writing codes or doing any tasks which needs creativity. And It helps me 😊

Can you link the studies that point the performance and quality of work done in pairs?

We worked in this way (Full stack dev): Everyone pulls a random ticket from the ticket pool (So this way on the long run everyone gets to know every part of the software) than if someone felt like doing pair programming or needed help or had time from the other end, we just openly talked/helped/pair programmed/asked who needs help. And we were all wary that not constantly pointing out mistakes, but rather point the one typing "driving" to the right direction and always communicationg on our ideas. I enjoyed this allways. And ofthen happened where I went away a little bit (for 15 mins) to think through for example a function and write it on my own then go back and show my peer and discuss if that is good/bad. I think peer programming is amazing.

I can totally agree with this. I use this technique with a friend, we reflected that our experience raised a lot and we also work faster. As we found out it's important to be critical about your own code and also about your partner's code, don't be afraid to discuss the solutions. Think about it together and as always in programming, don't get frustrated when someone found a better solution, sharing knowledge is quite important. From personal experience I noticed that discuss the code together brought out insane fast and short solutions for many Stuff we worked on. I recommend giving it a try. If you are an experienced programmer may try it with someone who has nearly the same level of knowledge before trying it with adepts.

"Students are cheaper to experiment on" gave me a hearty chuckle.

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..

Thank you, greats vids about pull requests and pair programming. I really like pair programming, I've done it without knowing it was a thing. Our error was not trying of taking it further and reacth out to the rest of the team and doing rotations.

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.

@ContinuousDelivery

3 жыл бұрын

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.

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.

@btm1

3 жыл бұрын

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

@ContinuousDelivery

3 жыл бұрын

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.

@jackb348

3 жыл бұрын

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.

@YvesHanoulle

3 жыл бұрын

@@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.

@YvesHanoulle

3 жыл бұрын

​@@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...

One combination that was missing here that I experienced was a senior developer with little to no domain knowledge paired with a junior developer with a lot of domain knowledge. This worked extremely well for the team.

Dave, thank you for this video. I found it highly informative and helpful.

@ContinuousDelivery

Жыл бұрын

Glad it was helpful!

Thanks a lot for the video!

@ContinuousDelivery

3 жыл бұрын

You are welcome!

@ContinuousDelivery is there a list of the studies you mention somewhere? Would be great :)

yeah okay, you got me on this one. liked and subscribed, greetings from germany

@rickarmbruster8788

3 жыл бұрын

grüße

@ContinuousDelivery

3 жыл бұрын

Welcome aboard!

I will back you on the notion that it's liberating. Been there, done that. I work well solo, but I know that I am better with a decent partner. I did my first pair programming in college (which I think was the point that the xtreme authors considered the origin). It was thrilling and the pace of code production, in my experience, was incredible. I admit that my experience is a bit limited, but I have found that 2 programmers produce the work of more than 2 programmers working independently. Yes, perhaps this is exceptional and I deeply expect that it was due to my partners being very good friends prior to the work.

@_Mentat

3 жыл бұрын

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

I've done daily rotation and it's, by a large margin, my favourite mode of working. The knowledge spread is next level and ownership is spread across the team and the app. Never once heard anyone say, "Oh, well, so-and-so knows that part of the app better so let's wait until they're back to take care of it" or "Ohhhhh boy well so-and-so wrote this code and they'll be mad if I rewrite it" and most importantly, "I don't think I should go on vacation in case this part of the system breaks and I'm the only one who really knows how it works."

@ContinuousDelivery

Жыл бұрын

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

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.

@vorrnth8734

2 жыл бұрын

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

I did this for a week in 1988. Two of us were assigned the same programming task, and decided to do it all together, rather than splitting it up. Our colleagues took the piss of us. At the end of a week of coding, we ran the C compiler, and it compiled first time! Pretty unheard of that we hadn't missed as much as a semicolon! It also worked first time! Not sure we'd ever repeat such success though!

Just was I was looking for! Great presentation on the value and things to pay attention on when starting. We had to discover the issue with seniors driving juniors ourselves. We are having some issues with the level of experience between junior and senior people where both lack experience in pair programming. We've created the notion of "sightseeing" where the senior person only navigates while the junior drives. The issue is that the junior needs to learn a lot of details at once, so the learnings don't stick as much. I'm wondering if a 3-person mob would let their brain cool down a bit between tasks, or if there's another way to help the juniors progress? Maybe give assignments where they can move slowly and then review together and pair up to fix their own code?

@ContinuousDelivery

3 жыл бұрын

I like the "sight-seeing" description. As I said in the video, IMO, the primary goal of a senior in this scenario is to help guide the learning of the junior. Not to tell them everything, but to allow them some freedom to try things out, experiment a bit and learn.

We did pair,group programming during certain fire drills, and it worked great.

Wow, never heard of it! What I use to do, coding alone, is writing 2 articles, 1 about the high level of the project (what the user gonna see), and other about the low level (what I'm coding). Not a code review exactly, but instead an overall view, frequently taking details into consideration. I use to be very harsh with myself, describing errors/bad designs/hacks as proof of crimes - of course I would not do that to someone else.

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.

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.

@ContinuousDelivery

3 жыл бұрын

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!

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.

@ContinuousDelivery

3 жыл бұрын

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.

@talideon

3 жыл бұрын

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.

@deanschulze3129

3 жыл бұрын

@@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.

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.

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.

@ContinuousDelivery

2 жыл бұрын

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.

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)

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.

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.

Thanks for the in depth explanation. How do you think will it work when the pair don't physically sit together?

@ContinuousDelivery

3 жыл бұрын

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!

Pair programming is not always useful, but! Pair programming is completely underrated!

@laponiec

3 жыл бұрын

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

For one on a team that can become extremely siloed, this is an attractive option. I look forward to trying it out

@ContinuousDelivery

Жыл бұрын

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

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

@Protocultor

3 жыл бұрын

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

How would I find the studies that show Pair Programming is beneficial?

@not_ever

3 жыл бұрын

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.

@colinfreyvogel3014

3 жыл бұрын

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

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?)

@ContinuousDelivery

2 жыл бұрын

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!

The daily rotation assumes a continuous integration pipeline of commiting and integrating more than once per day, right? Otherwise the new person that gets to work has an outdated codebase. If a team doesn't practice continuous integration and instead practices feature branching, what would your recommendation for pair programming be? Fix the two devs when a user story starts and keep them until it ends, and only rotate afterwards?

@ContinuousDelivery

2 жыл бұрын

I certainly think that pair programming works best hand-in-hand with CI, but I see no reason why pair rotation couldn't work with FBs too. It wouldn't be as good, but it wouldn't be as good because FB is not as good as CI, nothing to do with the pair programming as far as I can see.

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.

I'll first admit that I've never programmed in a pair full time. Still, I think the practice would often be too extreme - just like working in pairs on the same task is rarely done in other professions. Now, software development is a wide field, so there probably are a lot of situations where this practice may work well for some people. But, I think that a lot of the benefits can be gained by working with others in a more lightweight manner. I'd be happy enough with getting a few hours a week where 2 or more people are looking at the same code and sharing ideas.

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.

@citywitt3202

3 жыл бұрын

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

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.

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.

@QualityCoding

3 жыл бұрын

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/

@ContinuousDelivery

3 жыл бұрын

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.

@ContinuousDelivery

3 жыл бұрын

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

@jimhumelsine9187

3 жыл бұрын

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.

@thewalla07

3 жыл бұрын

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.

Pair Programming: loved by managers; hated by programmers.

@BittermanAndy

3 жыл бұрын

This.

@JJ-SH

2 жыл бұрын

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.

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.

@ContinuousDelivery

2 жыл бұрын

Thank you 😁

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.

Also, how is it applied in this pandemic? or for instance in long distanced teams.

@ContinuousDelivery

3 жыл бұрын

You can do remote pairing!

@michielthai9995

3 жыл бұрын

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

@georgeonearth

3 жыл бұрын

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

@michielthai9995

3 жыл бұрын

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

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

3 жыл бұрын

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.

@Greedygoblingames

3 жыл бұрын

@@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.

@ContinuousDelivery

3 жыл бұрын

@@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.

@thaianle4623

3 жыл бұрын

@@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?

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 ...

@thatoneuser8600

Жыл бұрын

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

That animated background is cool!

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

Interesting thoughts. Regarding your comment of committing every 15 mins. How would this work if committing means automated deployment that takes 5-7 mins?

@ContinuousDelivery

3 жыл бұрын

With a functioning deployment pipeline, you don't have to deploy off every commit, you deploy when the release candidate has finished evaluation and it, for anything that isn't very simple, will batch commits. Example: Commit stage (CI) take 5 minutes, Acceptance & Perf Testing take 50 minutes. So next time Acceptance Testing becomes free, there may have been 10 commits, so you test them all together as a small batch. You can then release if all the Acceptance and Perf tests pass.

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).

Where are the sources for the citations used?

@ContinuousDelivery

3 жыл бұрын

In the description for the video.

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".)

Seems like you really really need to time rotations well. Not all projects have same feature sizes or same cirumstances and I can easily see some project having too brief time in each pair so right as the benefits of cooperation start showing the cooperation gets interrupted by a rotation.

@ContinuousDelivery

3 жыл бұрын

Strangely you don't. I can't remember if I said this in the video, but U once worked on a team where we experimented with pair-rotation on an hourly basis. We all hated it, but it was, surprisingly, very productive. We stopped after one iteration though, because it was so tiring. Our productivity went up though, as far as we could tell, even though it wasn't a sustainable way to work.

This works for beginners or students

One suggestion I've heard for pairing is: Dev1: Types a test Dev2: Makes the test pass Dev2: Writes a test Dev1:Makes the test pass Has anyone tried this cadence? Where does the "refactor" part come in if doing this? I have worked with other devs on problems when someone got stuck, but not as a rule. I would be interested in trying it, but I'd really have to change our organization.

@ContinuousDelivery

2 жыл бұрын

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

@ddanielsandberg

2 жыл бұрын

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

Any suggestions for beginners in programming ?

@ContinuousDelivery

3 жыл бұрын

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

@hdjfjd8

3 жыл бұрын

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

@ContinuousDelivery

3 жыл бұрын

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

@travis1240

3 жыл бұрын

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

It works with students not for professionals competing to get that shiny recognition!

@ContinuousDelivery

3 жыл бұрын

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

it's a living nightmare for people with social anxiety, btw.

@ContinuousDelivery

3 жыл бұрын

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

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)

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...

About changing pairs every day, how about every week? for longer sprints? like monthly sprints.

@ContinuousDelivery

3 жыл бұрын

I think that every day works better. The aim is to get new ideas in to each story.

@georgeonearth

3 жыл бұрын

Team I was on where pairing actually worked, we rotated every half day. We rotated ticket ownership too. So I'd own a ticket at the start, pair with someone until lunch. We'd come back after lunch and my pair would own the ticket and I'd rotate off onto something else. Next morning, rotate again. Worked well

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.

This sounds like hell to me as an introvert. I think I will quit being a programmer if pair programming is prevalent.

@jonashellsborn7648

3 жыл бұрын

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

@mbartelsm

3 жыл бұрын

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.

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.

@paladinsorcerer67

2 жыл бұрын

@@andrealaforgia5066 Fair point, thanks for it.

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.

@ContinuousDelivery

3 жыл бұрын

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

@oliverglier8605

3 жыл бұрын

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

@edwardcullen1739

3 жыл бұрын

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...

For me, a programmer is like a painter painting a landscape, or like a carpenter making a cabinet. Somebody standing over my shoulder telling me to "complete this idea first" or "fasten down that screw now" is simply going to be a hindrance. Many of the "errors" in my code would be deliberate and transient, and simply reflect tolerances that allow for movement and solutions to emerging issues. It is also unlikely that anyone else would understand what I am doing until it is at least 75% done. I jump all over the place, deliberately leaving things inaccurate and incomplete until it is time to make them rigorous. This flexible, non-linear, "drilling down" approach actually lets the better ideas suggest and prioritize themselves, and for discovery to happen in a very natural and robust way. In a funny way, pair programming almost enforces a microcosm of a waterfall approach. It forces two programmers to be "on the same page" to some extent. The more people involved, the more defined that "page" has to be.

@ContinuousDelivery

2 жыл бұрын

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

@arithmetech

Жыл бұрын

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

@ContinuousDelivery

Жыл бұрын

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

@tahovig

Жыл бұрын

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

4:25 You could commit often, but not push to the branch, which most people are using.

@mbartelsm

3 жыл бұрын

He has various videos explaining why he dislikes working in branches

If hard data was something that influences the average manager decision in any relevant way, the corporate world would look very differently from how it actually does. For example you wouldn't have C-level execs on one hand acknowledging how overall productivity during lockdowns was higher than before and at the same time do the hardest push imaginable to bring people who just need a computer and an internet connection for their work to come back to the office.

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.

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.

I wouldn't rotate pairprogramming in a daily base. I would do in a feature base.

OHHH I'M COoOoOMMITTING!!!

I think you'd add value to this video by adding the references/citations for the pair-programming studies you cite :)

@ContinuousDelivery

3 жыл бұрын

I do, they are in the video description.

@roshan8853

3 жыл бұрын

@@ContinuousDelivery Apologies! I found them as soon as I posted!