An Experiment in Month Long Pairing
Pairing is a concept in software development that has more varying opinions than we have exposed bricks in our edgy, hipster office space.
This isn’t an article that is going to tell you why you should or shouldn’t pair, but rather one to tell of our specific experience pairing for a month straight and why pairing should always be a topic of discussion within your team. Different members on the same team are bound to have various thresholds for pairing, and sometimes conflicting opinions on its worth, not to mention management’s opinions on whether it is a valid use of developer time. This will always create some tension, but with effective retros, talking about how the members feel about pairing, and an Engineering Manager that is engaged and looking for opportunities to increase positive interaction between team members, good value can be had from pairing that can manifest itself in surprising ways.
We are Andrew and Amber Lott, two software engineers on the same team, and this is our account of a brilliant experiment suggested by our manager, Mariana. Given the excellent research on pairing as a way to increase the skills and improve the work of both developers involved, we took that idea all the way to eleven. Amber and I decided to pair not for a couple of hours or for a couple of days, we committed to pairing every day for an entire month. This is what we learned.
Why were you interested in pairing?
Andrew: When I first started at Beam, I thought that all of the soft skills I had developed in my previous career would immediately transfer over to working in the software world. My confidence was also riding high on performing so well at my bootcamp. I was the first Jr Developer that Beam hired, so I didn’t have any peers with the same background and experience level with software development. During my first few months, I found myself less confident in my skills despite a lot of great feedback from other team members and management.
Pairing with senior developers often resulted in highlighting the wide knowledge gap between us. Although I would learn a lot, it often resulted in me coming away from the experience feeling less confident in my abilities rather than more. Even when I had insights, I was plagued with probably illogical thoughts that they were just teaching me by allowing me the space to state what they already knew. Though they were always friendly and encouraging, I wanted to contribute more, and I was frustrated that I wasn’t learning more quickly.
Then, I paired with a team member named Amber on a card and the overall experience was much more rewarding. Combining her three years of programming experience and my knowledge from working at Beam longer, we were able to both contribute to the conversation and produce stronger code.
The fact that we each brought experiences to the pairing that the other didn’t yet have made us both feel that what we contributed was necessary and important to the pairing’s success. It was immediately apparent that we both mattered, and neither of us held the other one back. I talked to my manager about how positive this experience had been, and she suggested possibly pairing with her for a month straight to build off of that experience.
Amber: I previously had conversations with my manager about working with new engineers to improve the on-boarding experience. My manager approached me with the idea of pairing every day for an entire month after Andrew mentioned how much he enjoyed our pairing session a few days prior. I was surprised, but jumped at the chance to spread some of the knowledge I had gained and help out a fellow engineer.
How did you feel going into the month of pairing?
Amber: Knowing someone would be observing my work made me both nervous and excited. I was still new to the company, so a lot of the business logic and code base was still unfamiliar. I hoped that I could quickly become an asset to the team through helping Andrew to become a stronger developer.
Andrew: I was pumped. The experience I had pairing with Amber had been so positive. I knew she had a lot more technical knowledge about using React and the IDE we both use, so I was looking forward to stealing as much knowledge about those things as I could, but I was also hopeful that this experience would help me be more confident and learn how to communicate better with my team. I also needed someone younger to teach me how to use emojis.
What were your expectations?
Amber: I had only paired with engineers with decades of seniority in my three years being a developer, so I expected our pairing to be a student and teacher experience. However, I also hoped that we would become more comfortable around each other as teammates and pairing partners.
Andrew: I was hoping that I would come away from the experience learning just as much as I had pairing with seniors, but also with some more confidence in my abilities.
What was the month of pairing like?
Amber: Half way into the experience, I was convinced Andrew was helping me more than I was helping him! Every mentoring experience is different, but for Andrew, gathering the confidence to be able to hold his own in developer conversations and choose more difficult tasks to complete made a huge difference. I quickly realized that Andrew’s knowledge was a valuable source of information, and changed my focus to supporting his ideas and boosting his confidence when he made a helpful suggestion or pointed out an error in my thought process.
Andrew: It would be impossible to recount all the technical little things that I gained, but I didn’t anticipate the amount of confidence I would gain from this experience. I always saw myself as the junior that contributed little to the team, and I viewed Amber as an active participant in the team. By realizing that we were receiving mutual benefits from pairing together on cards, I realized that I am also an active participant of the team. It allowed me to be more confident with putting my opinion forward in code reviews and to not shy away from taking the lead at times during pairing and making my voice heard.
What are some of the skills you developed?
Amber: I find myself using Rails console more to do database queries. Previously, I used complex sql queries to achieve the same thing; it just took longer. I also gained valuable business knowledge that Andrew had picked up before I was hired.
Andrew: By far the biggest take away for me was seeing how to utilize debugging better with React. No matter how many tutorials you do about building something, debugging is a different animal that I think is best learned by seeing how different people approach tackling a real life problem in your code base.
What are some lasting impacts from this experience?
Amber: I learned a lot about working as a team to achieve the team goals. I came from a background where every developer worked alone to achieve his or her own tasks. Working with Andrew taught me that working through difficult problems together can be very beneficial for deeper understanding and code stability.
Andrew: I think I am a much more effective member of my team after this experience. The act of gaining confidence opens up all the little ways you can contribute. I’m not going to pretend that I am as confident in my abilities as I would like to be, but I am much farther along in my journey of being a great team member.
How has the structure of management at Beam allowed for greater learning and understanding through pairing?
Amber: Our engineering manager completely facilitated this whole experience. It takes complete trust from upper management that an entire month of pairing between two engineers could produce more quality work, result in a greater quantity of work, and refine both developers in the process.
Andrew: Having 1:1 meetings with a manager that is intimately involved in our team allowed me to express my lack of confidence privately and find opportunities to address it through things like this exercise in pairing.
How did this experience change your perspectives on pairing?
Amber: We picked up a particularly difficult card towards the end of the month and ended up pairing for an additional week to complete our task. Even though our assigned time together had come to a close, we found ourselves choosing to pair through complexity as a support to each other, rather than going our separate ways. I see Andrew as a great person to bounce ideas off of, and refer to him often when I’m confused about the acceptance criteria of a card or have a general logic question.
Andrew: Before this experience, I viewed pairing as a tool for when I was struggling. I would have time boxed an issue, and when I hit that limit I would reach out for a pair, and a senior would come teach me how to fix it. When another developer would ask for a pair, I would never offer myself up for it. Through this experience I now realize when I ask for a pair, it’s the same thing any other developer is looking for.
Are you guys friends now?
Amber: Of course! Pairing with someone for a month will create a feeling of co-ownership over the code you produced together. He’s also the first person I go to when I don’t know what’s going on because I know him better than the rest of the team. I think Andrew and I bonded more than the average pair will, but then again, I’ve never paired for a month straight before.
Andrew: Yes! And I think that’s important. Obviously you are not going to become friends with everyone you pair with, but I think in general it creates more familiarity with your team members, and it opens up moments of laughter and camaraderie that are important to building effective teams.
So, a whole month? How was that different than short term pairing?
Andrew: The long term format gave me a chance to become comfortable in technical conversation and share my own perspective. Pairing on Amber’s cards helped me realize that developers with more experience don’t always know all the answers.Being so green when it comes to programming I think I had an idea in my head that everyone else knew exactly what they were doing. This was a great experience to realize we are all constantly learning and building together.
Amber: It is completely different! A short term pairing experience can be worked in between other projects and becomes the focus for only a few hours here or there. A month of pairing IS your job. Every project becomes something that you work on together and you’re more dedicated to the experience because you know the other person is counting on you to show up ready to solve your problems together.
What are your final thoughts on the month of pairing?
Amber: It’s not something I would want to do everyday. I think there are moments of self-learning and discovery that you miss out on when you are consistently paired with another developer. However, in this case it worked really well for us. If someone asked me to pair for a month next year, I’d know both of us would come out of the experience more comfortable and encouraged. I’d probably say yes.
Andrew: Pairing for a month may seem like a daunting task, and a lot to ask of team members and management alike. However, the results from pairing can allow for team members a deeper bonding, code understanding, and higher team performance. If you don’t become friends, you’re probably at least going to become better teammates through understanding each other better. If you have a team member who could use a confidence boost or experience working with another team member, consider teaming them up with someone that is only slightly more experienced than them. You might be surprised at the results.
Coauthor: Amber Lott
