DEV Community

Discussion on: Why I'm not a fan of pair programming

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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?

Collapse
 
niko profile image
Niko 👩🏾‍💻 • Edited

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.