Better together — Introducing pair programming to your team
Pair programming, the idea of sitting down with another human to walk through or develop a piece of code together, is often one of those “time for that” ideas that sounds really great but is rarely executed in practice. At League, we are lucky enough to have some really passionate folks to take ownership and drive initiatives they feel strongly about.
Cue Sam, a Sr. Web Engineer at League, who initiated a monthly scheduled, randomly selected, rotation of pair programming partners to our web team. I decided to sit down with Sam to get more insight on pair programming as a whole, as well as an idea of how he went about establishing this practice.
What do you enjoy the most about pair programming?
So many things! I love pair programming. It’s something that frequently gets talked about as a great way to improve your skills as an engineer, but before League I didn’t have a huge amount of experience with it. League has a large contingent of talented web engineers, and I wanted to find more opportunities to connect and learn with the broader team. Pairing more felt like the perfect way to get to know the wider web team and help everyone skill up, especially as we have a tendency to end up in work silos on our respective feature teams.
Pairing is a great way to improve your technical skills — you get insight into how other people work and how you can make improvements for your own code. It is also an excellent way to develop your technical communication skills. That is sometimes under-appreciated — we can often solve a problem in our own head, but to develop the skills to be able to explain that to another person is a key skill. And pairing really helps foster that.
Can you describe the pair-programming initiative you started?
We have a Web Pair Programming Slack channel that team members can join, and if you are part of the channel, then once a month there is an integration that will randomly pair up 2 to 3 people. Then you can schedule a meeting with the person or people you are paired with for about an hour. There is some social time to get to know each other, then work through a programming problem together.
It is very free-form so the structure can vary from session to session, but typically one person is in the driver’s seat and one person in the passenger seat. In terms of picking a problem, it is encouraged that folks bring an idea of something to work on and then they can decide in the meeting what to work on together. Some examples would be a UI component that is self-contained on a fresh ticket, or an interesting challenge that is small enough to get through some of it within the hour.
What advice would you give to others to make the most effective use of time?
I think a lot of folks coming into a pairing session for the first time don’t really know what to expect. It can be a challenge if people view it as “oh, another meeting in my day”. Having clear expectations around how the hour will be broken out and bringing a clear problem you want to solve can help you get the most of your session. Most of the sessions are very satisfying as you identify problems and start sharing knowledge — people start getting really into it. Taking the time to prepare and coming in with a defined problem or something you would like to learn more about adds a lot of value.
Also, try to show up with a sense of openness. It can be easy to show up and feel like you know how to solve the problem, but it’s really a collaborative exercise. There might be a solution in your mind that totally works, but there are typically many ways to solve a problem. So, being open to hearing how others might approach it will really help you. The main goal here is to learn, both from each other and with each other.
Where do you see the balance between having deadlines and meetings with making sure that there is space pair programming?
It’s an interesting and challenging problem to solve — time is a resource we never have enough of. Pair programming is a block in a calendar, but it is focused and engaging. It is a special hour you take. You’re not sitting in a meeting with dozens of other people hearing something described to you. Rather, it is very active and energizing. It gets me more motivated and more excited. I always come out feeling good after getting to know my coworkers and improving how I work.
When we were setting up the integration we discussed the frequency — biweekly came up but we landed on once a month. This cadence allows us to have regular sessions, but is not so frequent that it becomes a chore.
What kind of feedback have you received as a result of the initiative?
I sent out a small survey and so far everyone gave it a 5/5. Largely folks enjoyed seeing how other people worked, the exchange of experience and domains, and loved the social and learning aspects. Especially in a remote environment it created more “water cooler” moments.
More anecdotally, some of our junior developers said it was one of the most valuable things for them at League. It gave them an opportunity to work with other developers and the experience of having to walk through something outside of their comfort zone.
Pair programming is dedicating an hour to ask questions, learn about something new, and explore ideas in code. It can be hard to post a technical question in a large team channel where 100+ people are going to see it. Having a dedicated hour of one-on-one time creates a safe space where people can feel comfortable and truly connect in a remote environment.
—
Working together on a problem can improve team connections, upskill both technical and communication skills, and knowledge share across domains. We’re thankful to our team members like Sam who take ownership of an idea and can inspire others to collaborate on problems together. In the end, it didn’t have to be a huge time sink to accomplish the goals! It started simply with a Slack integration and a once-a-month meeting, and has made a tremendous impact on the team.
