Pairing can happen when a teammate is starting a new feature, stuck on an issue or even if they need a buddy to “rubber duck.” It’s important to not get frustrated, be honest, ask questions, and remember you both have the same goal: to resolve the issue. Both sides of the screen can learn, increase code knowledge and articulate engineering concepts out loud. It’s way easier than it seems.
It’s important to be a good pair partner. You don’t want to be a seagull (more on that later.) Here are some practices I’ve found that work for me when getting help and pairing remotely. Same rules apply if you’re pairing side by side!
Before the Call
1. Set up your machine
Before pairing or if you know you will be pairing soon, set up your environments. Rev up your code editor of choice, start your terminal to run the code, have all the files open and grab your headphones in a quiet place with good wifi.
Git Lens is a great plugin on VScode that allows you to see who wrote the code. I love seeing who was working in the file before me and asking them over Slack if they could help. Or, I stalk closed PRs on GitHub to see who in the past has done similar work. I usually like to let my partner know specifics on what I need help with.
Example: I’ll send them the JIRA ticket I am working on, a link to my open PR, or explain over Slack what I need help with so they can prepare and know what they are getting into. It’s also good to be familiar with your video/screen sharing of choice. Zoom has great features for remote control and annotating.
2. Google it
Google the issue/error and try everything you can before asking for help. Or at least let your partner know all the details before pairing. Make a list of everything you’ve googled and tried.
“I haven’t had time to research this but I’d love to work on it together” or “I’ve read and googled as much as i understand but I’m still having issues with XYZ” or “I have no idea where to start and this error scares me.”
Knowing what page you/they are on will allow you both to know where to start and have empathy for the situation.
Side note
Sometimes, google can slip your mind, you’ve had a rough week, just want direction, or you genuinely don’t know how to google or interpret whatever it is you googled. It’s important to not lose your patience or get upset if one of you don’t know something. Pairing is all about learning together to complete a task. Learning how to teach is HUGE and a win-win for the entire team.
You could be teaching members of your team the best ways to google! Share your knowledge with empathy and know everyone is at different levels.
During the call
1. Don’t take over
Pair: a set of two things used together or regarded as a unit.
Congrats! You’re a tiny team! No one is more superior to the other. One may have more experience, but the end goal is for both partners to learn and understand (equally on both sides) on how to resolve the problem.
It’s easier for more experienced team members to get remote control of the screen and finished the issue really quick. This doesn’t help everyone in the end. Once you hop on a pairing call, realize you are now a teacher. Teachers don’t take tests for their students. Same goes for code. Don’t do their work for them. Encourage them and lead them in the right direction. Give helpful hints, show them to the correct file, ask sneaky questions so they can figure it out on their own. It’s totally necessary to take control of their screen to save some time or poke around the code they have so far. Just don’t write every line for them.
Example: I was working on a project where I was learning React Hooks. A mentor and I were pairing on how to set it all up. Then he deleted all the code! I freaked but was able to write the code on my own again with little help. I think, the point of pairing, is to teach a teammate, so they won’t have to reach out again in the future. They grew off that pairing session and could probably go to other teammates and teach them while you could focus on other things. But, sometimes teammates need a couple pairing sessions for things to click. Everyone learns differently!
2. Don’t be a seagull
The seagull effect: when someone comes in, craps on all of your code, and then flies aways. This, doesn’t just apply pairing. Seagulls can be found in many life situations. They attempt to help you, make a bunch of changes and then leaves you hanging because they got overwhelmed with not knowing how to solve it, got too busy with their own work and leave you in a worse situation than when you stared. You then are left with no solution, no confidence, messy code, and maybe questioning your career life choices. You should both be flying together in the right direction! Not one crapping all over the place and flying away.
3. Ask Questions
Both participants should ask questions. Be honest with what you don’t understand. Having a partner explain something differently forces them to think of things in a different perspective and teaches them more about the code.
“Could you explain that differently? I’m not following.”
“I missed that, could you undo and do it again?”
“How much do you know about useState? I’m asking because I don’t want to waste your time explaining things to you that you already know!”
4. Have an opened mind and have patience
Maybe it’s your first time pairing with them on the team, or you have to explain something 3 times for them to understand it. It’s key to be patient with teaching and with learning.
After the call
Reflect!
Reflect on all the changes made in the code. Looking at the diffs on VScode or on GitHub allow you to clearly see the progress you made for the correct solution. If you end up being a reviewer on the PR, review it and leave helpful comments.
Try to remember and understand what worked in the call and what didn’t so next time, you can be more prepared so the process could maybe go smoother.
So, what did I miss?
I’d love to hear any other helpful tips and tricks you use to have productive team pairing sessions! Let me know below or reach out on Twitter. And remember, don’t be a seagull!
