I would like to share my personal experience with pair programming, especially from the perspective of an introverted developer. For me, pair programming means above all: loss of productivity and extreme stress. In theory, it may sound good to divide the tasks into 'driver' and 'navigator', but in practice, the more dominant part often takes the lead - and the other remains passive. This creates an imbalance that is neither productive nor motivating. Another major problem is that you never get into a state of flow. The constant synchronization of thoughts prevents the kind of deep concentration that is often necessary for creative and complex software solutions. Pair programming is incredibly energy-sapping - especially for introverts like me. After a whole day, I'm so exhausted that I want to give up everything, even though I love my job as a software developer. Pair programming can be useful for very specific problems. But for longer than an hour, I think it should be restricted under occupational health and safety law. I wonder if there have already been any studies on this - especially with regard to the psychological stress for introverts. If not, it would be high time! For me, pair programming takes away everything I value about software development: Personal responsibility, calm, focus and the joy of creative work.
Thanks for the overview. I have started to pair-program with the new team/company I have recently joined. At first I was reluctant to it and wanted my own space to think about the logic/problem/solution but after a few session I am starting to see the huge benefits to it! I'm really looking forward to many more pair-programming sessions with my colleagues :)
The statement that code ownership is a bad idea and that everyone on the team should share the code seems like a good idea at first but there is a learning curve involved with jumping between the different pieces. We experienced this when we coded a system that spanned database code, front end code and mainframe code. Every few months we needed to refresh on MVS/TSO/JCL/DB2 ...of course if the code base is small this works well. I think pairing works best on initial design approach before coding starts. And then it would be more of a team discussion.
I hate pair programming.. at least at my current company (never did it before): - the development is way way slower - the quality is not necessary better - It is very energy draining.. the need to explain every single character and discussing why I use X over Y is crazy - I can't focus if someone is talking, especially about some unrelated bullshit. - other devs usually don't take any breaks. That means sometimes I sit for 5 hours and talk about everything Sometimes we had a bigger problem, and we talked about it for hours and tried to solve it. Later after work I thought about the problem by myself quietly for few minutes and solved the problem in 30 minutes... I prefer to work alone and if I need help (or someone else needs help) I am OK with pair programming for max 1 hour. I also love to listen to music while coding and not blah blah blah.. Maybe I am not compatible with pair programming or maybe we are doing it wrong, I don't know.. But for me it is a nightmare. In my next job, I will explicitly ask if the company is doing pair programming.
@@alejandrocano88 Yes (this is my other account) and we started doing it for some people - mostly for newer/less experienced employees. I shared this video with the company I work for.
@@alejandrocano88 It's not forever and there aren't really any strict guidelines. Some people are doing it for an hour, or however long it takes to finish the task they are doing. I'm one of the inexperienced people so it has helped me a lot! I have 14 months of full-time work experience now.
Hey, great video. Perhaps you could look to what woody zuil has to say about driver/navigator. His definitions are a bit different, but it’s in the context of ensemble programming. I tend to follow his definition more
I've seen a talk from Woody in the past about mob programming, but I'm not sure how his driver/navigator is different from what I'm saying, can you elaborate? Btw, I also have a video about driver/navigator in more detail: ua-cam.com/video/jqGmL6Hf23k/v-deo.html
Great video! How did you make your description so professional? It has images, clear spacing? Is there a format or something you can use. Would love to know more
I would like to share my personal experience with pair programming, especially from the perspective of an introverted developer. For me, pair programming means above all: loss of productivity and extreme stress.
In theory, it may sound good to divide the tasks into 'driver' and 'navigator', but in practice, the more dominant part often takes the lead - and the other remains passive. This creates an imbalance that is neither productive nor motivating.
Another major problem is that you never get into a state of flow. The constant synchronization of thoughts prevents the kind of deep concentration that is often necessary for creative and complex software solutions. Pair programming is incredibly energy-sapping - especially for introverts like me. After a whole day, I'm so exhausted that I want to give up everything, even though I love my job as a software developer.
Pair programming can be useful for very specific problems. But for longer than an hour, I think it should be restricted under occupational health and safety law. I wonder if there have already been any studies on this - especially with regard to the psychological stress for introverts. If not, it would be high time!
For me, pair programming takes away everything I value about software development: Personal responsibility, calm, focus and the joy of creative work.
Thanks for the overview. I have started to pair-program with the new team/company I have recently joined. At first I was reluctant to it and wanted my own space to think about the logic/problem/solution but after a few session I am starting to see the huge benefits to it! I'm really looking forward to many more pair-programming sessions with my colleagues :)
The statement that code ownership is a bad idea and that everyone on the team should share the code seems like a good idea at first but there is a learning curve involved with jumping between the different pieces. We experienced this when we coded a system that spanned database code, front end code and mainframe code. Every few months we needed to refresh on MVS/TSO/JCL/DB2 ...of course if the code base is small this works well.
I think pairing works best on initial design approach before coding starts. And then it would be more of a team discussion.
Thank you for the great video. We're only going to use pair programming in our team so I found it extremely useful.
Thanks for this mate!
I’m sure to learn a lot from you!
Cool video! Appreciate the helpful tips🤩
I hate pair programming.. at least at my current company (never did it before):
- the development is way way slower
- the quality is not necessary better
- It is very energy draining.. the need to explain every single character and discussing why I use X over Y is crazy
- I can't focus if someone is talking, especially about some unrelated bullshit.
- other devs usually don't take any breaks. That means sometimes I sit for 5 hours and talk about everything
Sometimes we had a bigger problem, and we talked about it for hours and tried to solve it. Later after work I thought about the problem by myself quietly for few minutes and solved the problem in 30 minutes...
I prefer to work alone and if I need help (or someone else needs help) I am OK with pair programming for max 1 hour.
I also love to listen to music while coding and not blah blah blah..
Maybe I am not compatible with pair programming or maybe we are doing it wrong, I don't know.. But for me it is a nightmare.
In my next job, I will explicitly ask if the company is doing pair programming.
I have a code paring interview coming up. This video is helpful.
Great content mate.
Im going to propose this at the start-up im workign at 🎉
did you?
@@alejandrocano88 Yes (this is my other account) and we started doing it for some people - mostly for newer/less experienced employees. I shared this video with the company I work for.
@@WebDevJapan thank you for the answer, if you don't mind me asking, how many hrs a day is reserved for pair programming, and is it for ever?
@@alejandrocano88 It's not forever and there aren't really any strict guidelines. Some people are doing it for an hour, or however long it takes to finish the task they are doing.
I'm one of the inexperienced people so it has helped me a lot! I have 14 months of full-time work experience now.
Great video, would love to hear your thoughts on pair programming between a junior and senior dev, more of a mentor/mentee role
I recommend you read the "Different skill levels" section of this article:
martinfowler.com/articles/on-pair-programming.html#DifferentSkillLevels
Hey, great video. Perhaps you could look to what woody zuil has to say about driver/navigator. His definitions are a bit different, but it’s in the context of ensemble programming. I tend to follow his definition more
I've seen a talk from Woody in the past about mob programming, but I'm not sure how his driver/navigator is different from what I'm saying, can you elaborate?
Btw, I also have a video about driver/navigator in more detail: ua-cam.com/video/jqGmL6Hf23k/v-deo.html
Great video! How did you make your description so professional? It has images, clear spacing? Is there a format or something you can use. Would love to know more
Do you mean the chapters? YT generates the design itself, I only provide the "0:00 Intro, 0:20 Chapter 1" etc.
@@branvandermeer I think UA-cam did an update and I just realized it when viewing your video. I thought there was some kind of code you used.
Great content!! thank you!
This was helpful. Thanks!
Great video,
Subscribed!