For the first few weeks of the immersive web development boot camp I started at Lighthouse Labs, we had weekly pair programming sessions with our classmates. The goal of these exercises was to help us think more critically about our coding process and the code we were writing, and to improve our communication and teamwork skills.

As someone who went into the boot camp with somewhere between a beginner and intermediate level of understanding of web development, I thought I would always take the lead in these sessions. That was my first big mistake, because I assumed that there should be a lead. That isn't actually one of the roles in a pair programming dynamic, which I quickly found out.

Different Aptitudes

I'd put myself on a pedestal and told myself that I'd be guiding the first pair programming exercise of the course, teaching my partner and guiding them through it. Imagine my surprise when we began our pair programming session and I became completely flustered with the exercise, while my partner understood right away what the exercise asked for.

Despite being completely new to web development, my partner took on the "strategic" role, otherwise known as the "navigator." This role takes a birds-eye view of the code, at the same time reviewing the code being typed and providing "big picture" commentary of where to go. I took on the "tactical" or "driver" role.

This was incredibly gracious of them, and let me focus on smaller bite-sized pieces of code, where I was feeling comfortable. As my partner laid out what small blocks of code we'd need to write to complete the exercise, and how they'd fit together, I realized they hadn't just relied on their previous experience like me, but had taken the time to prepare specifically for working with another person in real-time.

Different Communication Styles

What made this pair-programming exercise so successful was my partner's patience, constant communication, and encouragement.

Far from the micro-managing that I had planned to do, my partner painted a big picture of how the code should look. That let me focus on the implementation, which was smaller pieces that we could eventually fit together.

My partner also encouraged me to talk through what I was coding, both so that I could better understand what I was writing, but also so that they could have a better idea of my thought process.

Several times throughout the process, we switched roles, and my partner always asked helpful prompts while explaining their code. Their prompts usually consisted of asking me if our current code adhered to the layout we had established at the beginning of the exercise.

How I Learned to Adjust

Early into our pair-programming exercise, I had shed the somewhat arrogant approach of wanting to "lead" the team. Instead, I was too preoccupied with asking questions of my partner, and answering theirs, to think about who was the top dog.

I am naturally quiet when I code, and am not used to communicating what I'm typing. My partner encouraged me to speak up whenever I got too quiet, and this did a lot to bring me out of my shell and vocalize my thought process. It was incredibly helpful, because several times, I was able to catch myself carrying out a logical error before I'd even typed it out.

I paid attention to my partner's style as the navigator, and made sure not to micro-manage them when it was their turn to sit in the driver's seat. Instead, I just referred to our written-down original plan. I gave encouragement when they successfully implemented a part of that plan, and asked patient questions when it seemed they were straying just a bit.

How It Helped Me Grow as a Developer

Pair programming has taught me a lot about how I code, but mainly it's taught me how to become a better communicator. It's often better to say less, but to make each interaction more meaningful.

At the same time, it's important to regularly talk through code that I'm writing, especially if I'm the driver in a pair-programming assignment. One of the techniques we're taught at Lighthouse Labs is talking to a rubber ducky to help navigate difficult programming questions. Pair programming helped lower the bar for me in starting this practice, which has been incredibly helpful. In a way, my first pair programming partner was like a helpful rubber ducky.

Finally, pair programming taught me to trust my colleagues and peers, and not to think too highly of myself. Even when one has weaknesses, whether they be technical or communicative, there is often a strength elsewhere that can be leveraged to complete a project. As well, weaknesses can be strengthened, especially when you have someone in your corner who is willing to work with you to address them.