New to Honeycomb? Get your free account today.
Software changes so rapidly that developing on the cutting edge of it cannot fall to a single person. When it comes to asynchronously disseminating information about projects, code comments, PR conversations, Slack, RFCs, and other investigatory documents do a wonderful job, but no amount of async communication replaces the magic of two brains bouncing ideas off of each other. Especially in a remote-first environment lacking in-person whiteboarding sessions, collaborating through synchronous pair programming introduces a level of shared context that proves to benefit the people as well as the codebase.
The importance of pair programming
The non-profit coding bootcamp I attended has a longer-than-usual program length because the curriculum heavily incorporates soft skills. To get accepted into Techtonica, participants must show up to mandatory pair programming workshops as well as pair 1:1 with a staff member. Since the cohort engages in pair programming on a daily basis, acceptance into the program depends on an applicant’s ability to work well with others as well as communicate verbally about technical topics.
I knew to appreciate the regular interview question practice and recurring soft skill meetings that touched on a variety of workplace topics, but it took getting on a more senior engineer’s nerves for the first time, a volunteer office hours mentor, to appreciate that the quality and success of pair programming really depends on what both people bring to the session.
When he asked a question about my project, I gave a long-winded reply that didn’t actually answer it. He could have rephrased it and moved on, but instead he made the braver, kinder choice to stop and tell me the truth (feedback is a muscle after all). The mentor shared that in a work environment, no matter how much he liked or didn’t like me, his head would fill with thoughts about how time gets wasted listening to me wax on about something other than what he asked.
I look at this exchange as a pivotal moment in my career that triggered an ongoing curiosity about how to make the most of pair programming. Luckily, as an intern at Honeycomb, I had abundant opportunities to drink from the learning firehose at every turn.
Not only did I pair weekly with every member of my product team including mid-level, senior, and staff engineers, I also had access to donut pairing sessions through Slack, and many generous ICs from all over the company repeatedly offered to pair when I asked questions publicly through a channel.
After the internship ended and I stayed on as a junior software engineer, the training wheels of built-in guaranteed daily pair programming with my team got taken away. I had to take ownership over arranging my own pair programming sessions, and this transition introduced hyper-awareness that the key to maintaining a stream of pairing for my own growth would depend on bringing value, but maybe more importantly, not annoying the people who helped me so they’d help me again.
Pair programming best practices
In celebration of my first Honeyversary, I’ve reflected on these experiences and reached out to a handful of the aforementioned engineers with plans to document what made pair programming great between us. Every relationship gets contextualized by nuances that won’t get captured in a general list on the internet, but this is a synopsis of best practices based on our collective experiences at a people-first, diverse company of professionals from all different backgrounds.
No matter the engineering level, good pair partners:
DO:
✅ Honor the other person’s time by: being prepared, starting/ending on time, and showing gratitude for their contribution
✅ Consider giving specific kudos to the other person’s manager after the session if it went well so they can be recognized as a collaborative employee
✅ Discuss goals and expectations for the session
✅ Ask for feedback to be the most effective pair partner possible
DON’T:
❌ Forget to complete any next steps after the session
❌ Steamroll others and cause contribution imbalances
Junior devs requesting time with more senior engineers make for a good partner if they:
DO:
✅ Try things in advance and document them (bonus points for separate branches with good commit histories that show code examples of the attempts)
✅ Contextualize the pairing session request with a thoughtful question so the pair partner can show up in the right mindset or point you to a better resource
✅ Reiterate new information verbally to confirm understanding before moving forward
✅ Ask for advice concerning what to investigate and learn next to continue growing
✅ Recognize that the more senior an engineer, the more the company pays for their time (read: don’t waste these precious minutes)
DON’T:
❌ Underestimate their value as a pair partner
❌ Answer questions without verifying what actually got asked
❌ Overburden one person with all pairing requests
Senior devs pairing with less experienced engineers make for a good partner if they:
DO:
✅ Err on the side of over-explaining when they aren’t keenly aware of the other person’s skills
✅ Contextualize questions with the why so a junior dev doesn’t feel like they’re taking a pop quiz
✅ Take time to assure the other person that helping them is also of personal benefit
✅ Give thoughtful feedback and advice that extends beyond the session—think career-development practices as well
DON’T:
❌ Scroll and click a ton without giving context. Making people guess the what blocks them from understanding the why
❌ Express annoyance with the other person for not knowing enough
Everyone should gain something from a 🍐programming session
Good pair programming sessions benefit both parties. A junior’s success definitely accelerates by utilizing the right help to become more technically proficient, and so too does a senior’s success when they merge their technical skills with leadership qualities, like mentoring and effective communication across all engineering levels.
Recognizing the shared benefits of pair programming introduces a level of mutual respect and feelings of worthiness that improve the experience of each individual, which in turn positively impacts the organization’s overall health.
Did you like reading this piece? Continue your reading journey: Simulation Theory, Observability, and Modern Software Practices.
