Dev Rel & Live Coding Streamer. Obsessed with using code, inclusion, & design thinking to bring big ideas to life and tell digital stories worth sharing.
I try to pair program at least once or twice a week and find it very productive. Even when our coding levels couldn't be more different, I think how differently we think helps the process and quality of code that we write. If I'm less familiar, I'll ask a question to clarify and my partner voicing helps refocus our efforts. If they are "driving" and I'm familiar enough with the what we're doing then while they are focusing on the code being typed, I'm kind of 'eye in the sky' catching typos or odd syntax in real time. When we run into a particularly annoying bug, while one of us is doing exploratory debugging, the other is consulting documentation and other resources that might shed light on the issue. And the final thing I appreciate about it is that I've found myself way more likely to push through difficult blocks sooner when I'm pairing and tbh I'm not sure why. Maybe it's because someone else besides me is also invested and I want to succeed more for the both of us or that even though I'm putting in more effort and spending longer amounts of time, because I'm sharing the process ( aka double the knowledge base, double the resourcefulness, double the thought/idea sharing might equal only half the stress/frustrations for me.
I've paired with every engineer member of my team at least once in the last 2 months and am definitely a fan, but if you don't enjoy the process I don't think you should have to force yourself. If I felt pressured to do it, I doubt I'd be so fond of it. In my team we take on issues/tickets at will and are free to offer to pair with someone or open ourselves to being consulted on an as needed basis if they're working on something we find interesting/want to learn more about/ if we can offer some uniquely helpful/expert support. Alternately you can voice your interest in getting a pair partner for any issue you're working and those willing step forward. It has made me particularly more confident in assigning myself to issues that I deeply want to try my hand at but that are without a doubt above my current ability to tackle alone :D.
I'm glad that you are finding it effective. What I find interesting is that you say you only do it once or twice a week. Does this mean that you nonetheless spend most of your coding alone (or rather, not in a formal pair programming arrangement)?
Regardless of what we call it, I'm strongly in favour of having members of a team work together on small projects. It provides a good knowledge exchange and can help people share knowledge. But the "pair programming" I have concerns about is a specific process with rules and expectations. Would you say what you do is truly pair programming, or more of a informal cooperation?
Dev Rel & Live Coding Streamer. Obsessed with using code, inclusion, & design thinking to bring big ideas to life and tell digital stories worth sharing.
Hiya, yeah I think we're definitely on the same page regarding the awesome of team contribution :). I pair "at least" once or twice a week, but I meant that in reference to specific issues instead of instances. I pair until the new feature is shipped or issue resolved whether that means a duration of only 30 mins - a few hours in a single day or regularly scheduled meeting times over the course of a few weeks. How much time I spend coding solo or pairing shifts each week based on the complexity and priority of the issues I'm currently working on that would benefit from it. I'm generally working on multiple tasks during the week at the same time (some programing and others product/UX/research).
IMO it is truly pair programing since: 1 workstation is used, one of us is driving focusing of strategy/improvement, the other is navigating focusing on tactical implementation of the code, and we switch roles during the process. I feel all of that still fits the agile method core values and principles of the practice where "requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.[1] It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change". The informal nature my company takes to the forming of pairs, letting them naturally arise from preferences of the engineer assigned to a task or inspiration to form a pair based on team opinion that 2 of us would benefit from teaming on a particular issue due to our strengths and domain knowledge-base that relate to aspects of the task, and how we schedule out when/how we'll meet to fit work on the issue into both of our schedules around our other responsibilities is more team culture IMO. I'm ok with the rules and expectations of pairing currently, but my understanding/experience of them doesn't include the pure coding you mention. I super support your wanting to explore ways the methodology and others miss the mark though. Nothing's perfect and questioning accepted behaviors often leads to great discussions and growth.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I try to pair program at least once or twice a week and find it very productive. Even when our coding levels couldn't be more different, I think how differently we think helps the process and quality of code that we write. If I'm less familiar, I'll ask a question to clarify and my partner voicing helps refocus our efforts. If they are "driving" and I'm familiar enough with the what we're doing then while they are focusing on the code being typed, I'm kind of 'eye in the sky' catching typos or odd syntax in real time. When we run into a particularly annoying bug, while one of us is doing exploratory debugging, the other is consulting documentation and other resources that might shed light on the issue. And the final thing I appreciate about it is that I've found myself way more likely to push through difficult blocks sooner when I'm pairing and tbh I'm not sure why. Maybe it's because someone else besides me is also invested and I want to succeed more for the both of us or that even though I'm putting in more effort and spending longer amounts of time, because I'm sharing the process ( aka double the knowledge base, double the resourcefulness, double the thought/idea sharing might equal only half the stress/frustrations for me.
I've paired with every engineer member of my team at least once in the last 2 months and am definitely a fan, but if you don't enjoy the process I don't think you should have to force yourself. If I felt pressured to do it, I doubt I'd be so fond of it. In my team we take on issues/tickets at will and are free to offer to pair with someone or open ourselves to being consulted on an as needed basis if they're working on something we find interesting/want to learn more about/ if we can offer some uniquely helpful/expert support. Alternately you can voice your interest in getting a pair partner for any issue you're working and those willing step forward. It has made me particularly more confident in assigning myself to issues that I deeply want to try my hand at but that are without a doubt above my current ability to tackle alone :D.
I'm glad that you are finding it effective. What I find interesting is that you say you only do it once or twice a week. Does this mean that you nonetheless spend most of your coding alone (or rather, not in a formal pair programming arrangement)?
Regardless of what we call it, I'm strongly in favour of having members of a team work together on small projects. It provides a good knowledge exchange and can help people share knowledge. But the "pair programming" I have concerns about is a specific process with rules and expectations. Would you say what you do is truly pair programming, or more of a informal cooperation?
Hiya, yeah I think we're definitely on the same page regarding the awesome of team contribution :). I pair "at least" once or twice a week, but I meant that in reference to specific issues instead of instances. I pair until the new feature is shipped or issue resolved whether that means a duration of only 30 mins - a few hours in a single day or regularly scheduled meeting times over the course of a few weeks. How much time I spend coding solo or pairing shifts each week based on the complexity and priority of the issues I'm currently working on that would benefit from it. I'm generally working on multiple tasks during the week at the same time (some programing and others product/UX/research).
IMO it is truly pair programing since: 1 workstation is used, one of us is driving focusing of strategy/improvement, the other is navigating focusing on tactical implementation of the code, and we switch roles during the process. I feel all of that still fits the agile method core values and principles of the practice where "requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.[1] It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change". The informal nature my company takes to the forming of pairs, letting them naturally arise from preferences of the engineer assigned to a task or inspiration to form a pair based on team opinion that 2 of us would benefit from teaming on a particular issue due to our strengths and domain knowledge-base that relate to aspects of the task, and how we schedule out when/how we'll meet to fit work on the issue into both of our schedules around our other responsibilities is more team culture IMO. I'm ok with the rules and expectations of pairing currently, but my understanding/experience of them doesn't include the pure coding you mention. I super support your wanting to explore ways the methodology and others miss the mark though. Nothing's perfect and questioning accepted behaviors often leads to great discussions and growth.