For developer teams, I have enjoyed seeing ways that pair programming can to grow team morale, make better code and help share knowledge. In general, pair programming encourages developers to gang up on strategic or challenging problems. As I reflect upon some of my favorite times from my teams, I loved the times that we used pair programming to kill the road block or flow problems.
Here are some of the general benefits of pair programming:
Two minds make better code: Doug Shimp, one of my early Scrum trainers, used to promote the phrase that no mind should work alone. Pair programming gives team members a concrete practice and pattern for collaborating on problems. As I pair, I want to avoid my partner from feeling like I am micro-managing them. It is ok to have the coder make mistakes to enable them to figure out a problem on their own. Compilers, linters, and test automation should catch large classes of errors.
Better code: In formal software engineering studies, peer reviews have become one of the top practices to help find construction bugs early. If your team practices pair programming from time to time, it has similar properties to a peer review. Code is not everything too. It is important for agile teams to take time to design together. In the initial stages of a feature, pairs can sketch out a design (UML, component model, entity relationship diagram, etc.) and talk through strategy at a higher level.
Blending strengths: Teams might find it helpful to pair together to combine team strengths. Let us say that you have a feature that really requires front-end and back-end work. Could the feature go faster if a back-end engineer and a front-end engineer took a couple of hours pair programming together to hammer out essential details? I have enjoyed pair programming with our data science team. It has been fun to trade ideas. (ML stuff and agile engineering concepts)
We are social: As humans, we have an inherit need to connect to each other. Even if you are introverted, there is still a deep human need to connect to groups and peers. When I am pair programming, I am less likely to check email and social media since I want to make sure I am appropriately engaging with my partner. There is a special kind of flow or fun factor that happens when you are ganging up on a problem.
Sharing knowledge and discipline: If you are introducing team members into a new code base, it can be helpful to give them a tour of the code base while getting some work done. Let us say that you are trying to encourage a team to do more unit test development in your server code. It can be helpful to pair program to talk through the construction ideas, ways to make useful tests, and other design ideas. In general, pair programming can be a wonderful teaching tool. I love learning new IDE tricks and tools from other developers.
So... How do you do pair programming well?
Like many, I am still trying to become more effective at pair programming with my team. I am also encouraging my team members to pair program with each other. I drafted this blog post to collect a few practices to help me and my team to grow.
Start with 2 to 4 hours per week: Through our Google DevFest conference, I had learned that Pluralsight executes a great deal of pair programming in their mobile engineering team. It became very tempting to recommend day long pair programming sessions. A sizable number of blog posts recommend starting small. (2 to 4 hours per week) After the team experiments with these small experiences, teams can decide organically about using the practice more.
Define a good schedule, tools, and scope: Pair programming sessions should have a clear schedule and goal. During the pair programming session, block out email/social communication to deeply focus on the experience and the needs of your partner. If you commit to pair programming for one hour, make sure to stick to your time box to respect everyone’s time. As a team, consider talking about the common tools that will make pair programming more productive. Encourage experimentation.
Talk while you make stuff: It is often helpful to talk through your thought process while you are coding. The act of asking questions or talking helps increase the clarity of problems before you. During the pair programming session, the person who is not coding (supporter) can help you reflect and follow your mental model. I really like the concept that the supporter actively complements those activities of the coder. The supporter might search for useful blog posts, sketch out design ideas, and help the coder avoid errors in real time.
Every 30 minutes, pass the keyboard: To encourage equal coding time, I like to encourage the practice of passing the keyboard at regular intervals. You and your partner can decide on what works for you. As you pair, make sure to schedule breaks.
References:
Photo attribution: https://flickr.com/photos/rafaelmob/
Looking for a role where your app makes a difference? Are you passionate about empowering people and growing the next generation of VR/AR training? If you're an experienced full-stack web developer looking to grow your mastery, consider learning more about DI's high impact career opportunities at https://bit.ly/36Um4J0
Top comments (2)
nice
In my experience it's absolutely the worst way of working, and a sure-fire way to reduce productivity. It makes development awkward and cumbersome