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
@rstehwien3 жыл бұрын
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).
@VideoGameBoxReviews11 ай бұрын
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.
@omarsuriel11123 жыл бұрын
This channel is lit 🔥 it gives us a lot of engineering gems 💎 that are rare to find these days specially as self taught developers
@ChapmanWorldOnTube3 жыл бұрын
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.
@murraynatkie74903 жыл бұрын
At a minimum, every time you commit there are twice as many developers intimately familiar with the code if it needs maintenance.
@murraynatkie74903 жыл бұрын
@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. ;-)
@BittermanAndy3 жыл бұрын
@@mwwhited bingo.
@miledavitkovski13432 жыл бұрын
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.
@chrisjones50463 жыл бұрын
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.
@georgeonearth3 жыл бұрын
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.
@andrewashworth83273 жыл бұрын
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
@leonaRDO-ox8zg3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@thaianle46233 жыл бұрын
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.
@chudchadanstud3 жыл бұрын
@@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.
@Protocultor3 жыл бұрын
@@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.
@puterich3 жыл бұрын
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
@_winston_smith_3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@andrewadkins84403 жыл бұрын
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 .
@andrewadkins84403 жыл бұрын
@@_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.
@pappont3 жыл бұрын
I bet, you never really tried pair programming for any significant time. Only practice is the criterion of truth
@spinnetti3 жыл бұрын
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)
@m.x.3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@georgeonearth3 жыл бұрын
@@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.
@nlac732 жыл бұрын
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 :)
@edwardcullen17393 жыл бұрын
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
@manishm947810 ай бұрын
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 😖
@raulsantandertirado44003 жыл бұрын
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.
@ddanielsandberg3 жыл бұрын
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."
@Sunyatasattva3 жыл бұрын
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.
@NotMarkKnopfler3 жыл бұрын
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.
@_Mentat3 жыл бұрын
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".
@NotMarkKnopfler3 жыл бұрын
@@_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.
@ajward1373 жыл бұрын
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.
@travis12403 жыл бұрын
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.
@Omnifarious03 жыл бұрын
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.
@edwardcullen17393 жыл бұрын
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.
@Voidsway3 жыл бұрын
@@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.
@Golnarth3 жыл бұрын
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.
@a0flj03 жыл бұрын
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.
@Reriiru2 жыл бұрын
"Students are cheaper to experiment on" gave me a hearty chuckle.
@Elrog33 жыл бұрын
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.
@deanschulze31293 жыл бұрын
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-jn4sw3iw4h3 жыл бұрын
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.
@PatrikKron3 жыл бұрын
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.
@deanschulze31293 жыл бұрын
@@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.
@JojOatXGME3 жыл бұрын
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.
@mbartelsm3 жыл бұрын
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.
@jyrinx3 жыл бұрын
Sounds like you're introverted? Anyone who tends to get peopled out is going to get worn down.
@Luxalpa3 жыл бұрын
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.
@recklessroges3 жыл бұрын
Pair Programming: loved by managers; hated by programmers.
@BittermanAndy3 жыл бұрын
This.
@JJ-SH2 жыл бұрын
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.
@greyTigerGames3 жыл бұрын
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.
@btm13 жыл бұрын
it is really good for debugging or fixing difficult problems but a waste of time or even disruptive for day to day programming
@ContinuousDelivery3 жыл бұрын
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.
@jackb3483 жыл бұрын
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.
@YvesHanoulle3 жыл бұрын
@@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.
@YvesHanoulle3 жыл бұрын
@@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...
@tinker77223 жыл бұрын
Thanks for sharing your experience with us! You really seam to know what you're taking about! Great and encouraging speech!
@waperboy3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@ChiefsFanInSC3 жыл бұрын
@@ContinuousDelivery I am friends with several authors and none of them write in pairs.
@BittermanAndy3 жыл бұрын
@@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.
@AlphaMatt10003 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
Sorry you didn't enjoy it. I am the other way around now, I miss pairing when I code alone.
@oliverglier86053 жыл бұрын
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
@edwardcullen17393 жыл бұрын
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...
@CaimAstraea3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@Cyberspine3 жыл бұрын
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.
@PatrikKron3 жыл бұрын
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.
@pfote653 жыл бұрын
yeah okay, you got me on this one. liked and subscribed, greetings from germany
@rickarmbruster87883 жыл бұрын
grüße
@ContinuousDelivery3 жыл бұрын
Welcome aboard!
@MZO953 жыл бұрын
Can you link the studies that point the performance and quality of work done in pairs?
@rumble19253 жыл бұрын
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.
@vorrnth87342 жыл бұрын
Well for me personally this really exhausting. I can only deal with a certain amount of human Interaction per day.
@kmac4993 жыл бұрын
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..
@petersuvara3 жыл бұрын
Pair programming is not always useful, but! Pair programming is completely underrated!
@laponiec3 жыл бұрын
For me pair programming (when working on my private projects) is mostly a really great fun.
@Proactivity3 жыл бұрын
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
@leventeopelcz62033 жыл бұрын
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.
@CrossbowBeta3 жыл бұрын
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.
@deanschulze31293 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@talideon3 жыл бұрын
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.
@deanschulze31293 жыл бұрын
@@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.
@thulsadum3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@sdb5843 жыл бұрын
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.
@USONOFAV3 жыл бұрын
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.
@6754bettkitty3 жыл бұрын
That animated background is cool!
@andrewhaust33822 жыл бұрын
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."
@ContinuousDelivery2 жыл бұрын
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". 😁😎
@shavais333 жыл бұрын
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.
@crushingbelial Жыл бұрын
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
@akasusnevelas82943 жыл бұрын
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.
@debajitbiswas9770 Жыл бұрын
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 😊
@chriswheeler8143 Жыл бұрын
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!
@siyaram28553 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
Thank you 😁
@sebastian_tec3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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!
@iantaite3 жыл бұрын
How would I find the studies that show Pair Programming is beneficial?
@not_ever3 жыл бұрын
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.
@colinfreyvogel30143 жыл бұрын
@@not_ever there’s also a HUB of SCIence that one can use to get around paywalls
@hagenmuller45683 жыл бұрын
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
@ContinuousDelivery3 жыл бұрын
Glad you enjoyed it!
@while.coyote3 жыл бұрын
it's a living nightmare for people with social anxiety, btw.
@ContinuousDelivery3 жыл бұрын
You may find my post on "Pair Programming for Introverts" interesting: www.davefarley.net/?p=267
@Greedygoblingames3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@Greedygoblingames3 жыл бұрын
@@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.
@ContinuousDelivery3 жыл бұрын
@@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.
@thaianle46233 жыл бұрын
@@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?
@svenanton698 Жыл бұрын
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.
@cbrunnkvist2 жыл бұрын
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)
@lordlee64733 жыл бұрын
We did pair,group programming during certain fire drills, and it worked great.
@dimitrypolivaev16893 жыл бұрын
Great analysis and great explanations. Thank you so much!
@ContinuousDelivery3 жыл бұрын
Glad it was helpful!
@anj000 Жыл бұрын
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.
@runonce Жыл бұрын
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.
@addcoding81502 жыл бұрын
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
@ChokedByHalo13 жыл бұрын
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.
@arglebargle173 жыл бұрын
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.
@_Mentat3 жыл бұрын
No, the mediocre partner is amazed at what "they" have produced. Someone else did the work and they share the credit.
@beaujamo3 жыл бұрын
It works with students not for professionals competing to get that shiny recognition!
@ContinuousDelivery3 жыл бұрын
I think that depends on where the "professionals" work. It certainly is employed, and does work, in some professional settings.
@pinguwien Жыл бұрын
@ContinuousDelivery is there a list of the studies you mention somewhere? Would be great :)
@daviddelaney36319 күн бұрын
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.
@cfalguiere2 жыл бұрын
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
@AllanKobelansky3 жыл бұрын
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.
@gabiold3 жыл бұрын
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.
@gabiold3 жыл бұрын
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.
@joshstevens39913 жыл бұрын
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
@Protocultor3 жыл бұрын
Yeah, it's a "clickbaity" title, the only thing I didn't like about the video.
@SamanthaAndrews2 жыл бұрын
Dave, thank you for this video. I found it highly informative and helpful.
@ContinuousDelivery2 жыл бұрын
Glad it was helpful!
@HenryLoenwind3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@_Mentat3 жыл бұрын
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.
@HenryLoenwind3 жыл бұрын
@@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).
@proofit4043 жыл бұрын
Thanks a lot for the video!
@ContinuousDelivery3 жыл бұрын
You are welcome!
@sallylauper82223 жыл бұрын
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...
@georged86443 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
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.
@georged86443 жыл бұрын
@@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.
@ContinuousDelivery3 жыл бұрын
@@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.
@_Mentat3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
@@_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.
@MrAbrazildo3 жыл бұрын
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.
@pilotboba2 жыл бұрын
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.
@ContinuousDelivery2 жыл бұрын
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.
@ddanielsandberg2 жыл бұрын
Yes, this is called "TDD ping-pong". :)
@chrispeng55023 жыл бұрын
This sounds like hell to me as an introvert. I think I will quit being a programmer if pair programming is prevalent.
@jonashellsborn76483 жыл бұрын
But what if you meet another nice person? Or are all the other ones in your team "seagulls"?
@mbartelsm3 жыл бұрын
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.
@roshan88533 жыл бұрын
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.
@citywitt32023 жыл бұрын
I’d suggest research, and if it doesn’t exist, build it :-).
@jimhumelsine91873 жыл бұрын
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.
@QualityCoding3 жыл бұрын
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/
@ContinuousDelivery3 жыл бұрын
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.
@ContinuousDelivery3 жыл бұрын
Yes, that matches my experience too. Nothing fancy needed and it works almost as well as sitting next to someone.
@jimhumelsine91873 жыл бұрын
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.
@thewalla073 жыл бұрын
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.
@icystrangers54822 жыл бұрын
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.
@ContinuousDelivery2 жыл бұрын
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.
@arithmetech2 жыл бұрын
@@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!
@ContinuousDelivery2 жыл бұрын
@@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.
@about_midnightАй бұрын
okay but how do you do a power nap or a fridge blitzkrieg in pair programming?
@GenoppteFliese Жыл бұрын
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.
@beaujamo3 жыл бұрын
This works for beginners or students
@adamhendry9452 жыл бұрын
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)
@LightWrathme3 жыл бұрын
OHHH I'M COoOoOMMITTING!!!
@douglasmaclaine-cross9976 Жыл бұрын
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.
@asaflevy93873 жыл бұрын
Thanks for the in depth explanation. How do you think will it work when the pair don't physically sit together?
@ContinuousDelivery3 жыл бұрын
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!
@pappont3 жыл бұрын
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?)
@ContinuousDelivery3 жыл бұрын
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!
@JasonEDragon3 жыл бұрын
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.
@paladinsorcerer673 жыл бұрын
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.
@paladinsorcerer672 жыл бұрын
@@andrealaforgia5066 Fair point, thanks for it.
@akitmentorconsultant46962 жыл бұрын
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.
@Alexagrigorieff3 жыл бұрын
How about au pair programming
@ContinuousDelivery3 жыл бұрын
Depends on how "programmable" your Au pair is :)
@hdjfjd83 жыл бұрын
Any suggestions for beginners in programming ?
@ContinuousDelivery3 жыл бұрын
Yes, I asked my followers on Twitter for their advice to people who are just starting out, I got a couple of hundred replies. Here is a video on their replies and my own advice to people in the early stages of their career: kzfaq.info/get/bejne/ntB5n7eSprPXkn0.html
@hdjfjd83 жыл бұрын
@@ContinuousDelivery thanks for the assistance. Do you also have a Computer science /IT background ?
@ContinuousDelivery3 жыл бұрын
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”.
@travis12403 жыл бұрын
Get really really good at what you do. Look for domains (ML, security, UI, etc) that you are interested in and build domain expertise.
@eventhorizon8533 жыл бұрын
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.
@orvovosk Жыл бұрын
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.
@danieljoaquinsegoviacorona17343 жыл бұрын
Also, how is it applied in this pandemic? or for instance in long distanced teams.
@ContinuousDelivery3 жыл бұрын
You can do remote pairing!
@michielthai99953 жыл бұрын
It’s even easier remote, you don’t even have to switch seats or breath in each other necks
@georgeonearth3 жыл бұрын
@@michielthai9995 But you do have to constantly have a Slack session or similar open, which is fatiguing.
@michielthai99953 жыл бұрын
@@georgeonearth they key is that you do it for an hour or 2 max a day. It's same when pairing in person.
@hodsh13 жыл бұрын
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).
@azthecx3 жыл бұрын
Where are the sources for the citations used?
@ContinuousDelivery3 жыл бұрын
In the description for the video.
@porky11183 жыл бұрын
4:25 You could commit often, but not push to the branch, which most people are using.
@mbartelsm3 жыл бұрын
He has various videos explaining why he dislikes working in branches
@Layarion3 жыл бұрын
but how do you handle moments where one of you spends 2 hours researching how to solve the problem?
@ContinuousDelivery3 жыл бұрын
Spend the 2 hours to solve the problem! Usually do it together as a pair, bouncing ideas around.
@GK-op4oc3 жыл бұрын
"Pair Programming" disrupts those around you when the pair are joking around. There are definitely some developers that get lonely or unable to produce anything if they are asked to work independently.