I've pair programmed for most of my career. I've been able to learn so much through it, especially as a graduate engineer. I definitely found it helped us as a team deliver faster. It saved us needing to use PR reviews as we'd be constantly reviewing along the way.
Thanks for this engagement. I am encouraged. I am at this point that I stopped learning everything because is not working for me. I am just trying to make out something from things I have been learning. Thank you so much ❤
I find pair programming effective to solve a specific problem. It can be exhausting to pair program, so I don’t like it for everyday routine programming. It also helps that both parties are on roughly the same level of experience.
Interesting comment section. I can see pros and cons of pair programming. Sure you can cut corners on PR reviews or frogleap a junior programmer if pair programming, but to what cost? To become a great programmer I think the most important trait one can have is to be curious and rhe willing to learn for oneself. Our architect has really poor design and often implementing antipattern, unfortunately our joinior developers are learning/doing as he says. Best question a programmer can ask is, why? Why donit rhis way, whatnis the benefits, are we looking at a broken window or are we following some sort of well defined practices.
I like the idea of distributive programming, helps building team work and pushes you to keep the whole architecture of the code in mind. Emphasizes on the idea that one must draw the system and mark the key kpis and structures before starting to work on it.
More like the contrary. Pair programming slows productivity, increases costs and is unsuitable for routine coding. It can lead to personality clashes, restrict autonomy, and create constant negotiation and scrutiny, which frustrates independent-minded developers. The continuous collaboration can cause stress, burnout and a feeling of being micromanaged, especially for those who thrive on solo work. While it can help tackle complex problems, it's often an approach for less-skilled developers who need collaboration to produce quality code, and forcing it can feel like imposing rigid control on how people work best. Now, if by pair programming one means what developers have been naturally doing for decades, which is, sitting together for explaining, discussing or rubber-ducking about parts of the app in an organic way and of their own free will, by all means, go ahead.
I recall my best job where I learned the most (surrounded by brilliant motivated people all with different skills and interests; it was heaven) where we tried many techniques to improve knowledge transfer between team members. When it came to pair programming we floundered like nothing else. It definitely allowed us to share some knowledge but it was such a slow and inefficient way of coding. We were focusing on making each line the best it could be but any divergence in approach between members (even meaninglessly minor ones) would cause this disproportionate disruption. Learned much more from those 1-to-1s with those much better coders and leaders than me. That's it. Having people with 10/20/30 years of experience warning me something was a bad idea and me having to find out in real time why they were right - that's what grew me quick. Seeing how they thought through and solved problems, trying to understand the small things they cared about that I didn't. Debating with them about those things until I understood why they were important. Sometimes they weren't of course but mostly there was a very good reason I just didn't understand. Later on when becoming a lead myself, it was teaching that improved the precision of my thoughts as well as further chats with developers better than myself.
Pair programming only works when the personalities of both participants are more or less aligned. If not, it's going to be hell for at least one of the two. You should be careful of focusing too much on the productivity side of things, while ignoring the human and emotional stuff.
As a very senior engineer and architect this channel continues to have some of the worst takes and advice. Pair programming is an attempt by management to take 2 inferior devs and try to get them to perform well by shoving them together. Its absolutely terrible, frustrating , cost prohibitive and all around bad most of the time. The only time it is useful is for very specific, targeted tasks that tend to be complex or critical in some way. Or to train a brand new team member on the code base. But always for short periods and limited amounts of time.
Pair Programming also helps QAs that need to write automation testing code. Any reason why devs wouldn't write them at the time they made the feature code?
After 25 years in the programming world, I think no more than 5 of the 100 best (as in "relevant work competence") colleagues I ever had would agree with that title. So I think it's completely wrong.
Hello Sir, I'm a QA Engineer and I feel like I've reached the peak of what the position offers before moving into Management. Besides working with AI, what do you recommend for the future? How could I reach a $100k salary? Should I go back to being a developer? I was a developer for 8 years before moving into QA, where I've been for almost 10 years now. I don’t have any certifications, but I've worked in manual testing, automation, API testing, backend testing, performance testing, and lately I've been focusing on AI. I’d like to hear your opinion on career options and what I should study or pursue for future opportunities. What do you see as potential paths?
Please include a description of ensemble (mob) programming because it is another collaborative approach with a different effect. I have seen people try to pair program in situations that would be better addressed using ensemble programming.
I have a guide to getting started with Pair Programming, that you can get here: continuous-delivery.co.uk/downloads/Advice%20-%20Pair%20Programming%20Patterns%2006-04-21.pdf and funnily enough I have just started work on scoping out a video to demonPair Programming in practice...
Exactly. He should go back to work as a software developer, forced to pair program for a while. Let's see what he thinks about those pseudo-slavery methods later on.
Get Dave Farley's FREE guide to Pair programming ➡ www.subscribepage.com/cd-pair-guide
I've pair programmed for most of my career. I've been able to learn so much through it, especially as a graduate engineer. I definitely found it helped us as a team deliver faster. It saved us needing to use PR reviews as we'd be constantly reviewing along the way.
Thanks for this engagement. I am encouraged. I am at this point that I stopped learning everything because is not working for me. I am just trying to make out something from things I have been learning.
Thank you so much ❤
I find pair programming effective to solve a specific problem. It can be exhausting to pair program, so I don’t like it for everyday routine programming. It also helps that both parties are on roughly the same level of experience.
Interesting comment section. I can see pros and cons of pair programming. Sure you can cut corners on PR reviews or frogleap a junior programmer if pair programming, but to what cost? To become a great programmer I think the most important trait one can have is to be curious and rhe willing to learn for oneself. Our architect has really poor design and often implementing antipattern, unfortunately our joinior developers are learning/doing as he says. Best question a programmer can ask is, why? Why donit rhis way, whatnis the benefits, are we looking at a broken window or are we following some sort of well defined practices.
I like the idea of distributive programming, helps building team work and pushes you to keep the whole architecture of the code in mind. Emphasizes on the idea that one must draw the system and mark the key kpis and structures before starting to work on it.
I remember 2 years ago when you came to give an internal talk at Codurance, it was very good
I don't like oair programming except for specific complicated problems. Usually one person phases out or it's endless discussion.
More like the contrary. Pair programming slows productivity, increases costs and is unsuitable for routine coding. It can lead to personality clashes, restrict autonomy, and create constant negotiation and scrutiny, which frustrates independent-minded developers.
The continuous collaboration can cause stress, burnout and a feeling of being micromanaged, especially for those who thrive on solo work. While it can help tackle complex problems, it's often an approach for less-skilled developers who need collaboration to produce quality code, and forcing it can feel like imposing rigid control on how people work best.
Now, if by pair programming one means what developers have been naturally doing for decades, which is, sitting together for explaining, discussing or rubber-ducking about parts of the app in an organic way and of their own free will, by all means, go ahead.
I recall my best job where I learned the most (surrounded by brilliant motivated people all with different skills and interests; it was heaven) where we tried many techniques to improve knowledge transfer between team members. When it came to pair programming we floundered like nothing else. It definitely allowed us to share some knowledge but it was such a slow and inefficient way of coding. We were focusing on making each line the best it could be but any divergence in approach between members (even meaninglessly minor ones) would cause this disproportionate disruption.
Learned much more from those 1-to-1s with those much better coders and leaders than me. That's it. Having people with 10/20/30 years of experience warning me something was a bad idea and me having to find out in real time why they were right - that's what grew me quick. Seeing how they thought through and solved problems, trying to understand the small things they cared about that I didn't. Debating with them about those things until I understood why they were important. Sometimes they weren't of course but mostly there was a very good reason I just didn't understand. Later on when becoming a lead myself, it was teaching that improved the precision of my thoughts as well as further chats with developers better than myself.
Pair programming only works when the personalities of both participants are more or less aligned. If not, it's going to be hell for at least one of the two. You should be careful of focusing too much on the productivity side of things, while ignoring the human and emotional stuff.
RISC is about the semantic gap. Not the number of instructions.
As a very senior engineer and architect this channel continues to have some of the worst takes and advice.
Pair programming is an attempt by management to take 2 inferior devs and try to get them to perform well by shoving them together. Its absolutely terrible, frustrating , cost prohibitive and all around bad most of the time.
The only time it is useful is for very specific, targeted tasks that tend to be complex or critical in some way. Or to train a brand new team member on the code base. But always for short periods and limited amounts of time.
Pair Programming also helps QAs that need to write automation testing code. Any reason why devs wouldn't write them at the time they made the feature code?
So essential I've never seen it used in practice beyond experiments.
After 25 years in the programming world, I think no more than 5 of the 100 best (as in "relevant work competence") colleagues I ever had would agree with that title. So I think it's completely wrong.
Hello Sir, I'm a QA Engineer and I feel like I've reached the peak of what the position offers before moving into Management. Besides working with AI, what do you recommend for the future? How could I reach a $100k salary? Should I go back to being a developer? I was a developer for 8 years before moving into QA, where I've been for almost 10 years now. I don’t have any certifications, but I've worked in manual testing, automation, API testing, backend testing, performance testing, and lately I've been focusing on AI. I’d like to hear your opinion on career options and what I should study or pursue for future opportunities. What do you see as potential paths?
Please include a description of ensemble (mob) programming because it is another collaborative approach with a different effect.
I have seen people try to pair program in situations that would be better addressed using ensemble programming.
It may work in some particular complex cases, but it's awful in general.
Please share best practices to do it right...
I would also, deeply love, to see a pair programming session in action.
Keep rocking!
I have a guide to getting started with Pair Programming, that you can get here: continuous-delivery.co.uk/downloads/Advice%20-%20Pair%20Programming%20Patterns%2006-04-21.pdf
and funnily enough I have just started work on scoping out a video to demonPair Programming in practice...
More "no real scotsman" content from the Karen of our industry
Exactly. He should go back to work as a software developer, forced to pair program for a while. Let's see what he thinks about those pseudo-slavery methods later on.