This was originally an internal document about my personal approach and opinions about pairing (including, but not limited to pair programming). I’ve decided to publish it in case it sparks ideas for more people. It’s not a set of rules or policy you must follow. It’s just what works for me and based on feedback I’ve received it also works for others. If you want to skip the theory stuff jump ahead to the “let’s talk practice” section.
What is pair programming?⌗
Traditionally, pair programming is simply the act of two (or more) people working off a single editor to write code. Normally one person “drives” by being the person to actually type code and run commands while the other person helps navigate.
That’s the basics, but I like to extend this much farther by removing all that “programming” baggage from the act.
My version of pairing⌗
I like to pair with people I work with on all sorts of projects. Sure, there’s some programming, but more often than not the activity we’re pairing on is something totally non-code related. I’ve paired with people to write documentation, author internal processes, share general knowledge of organization lore, and yes, write some occasional code.
Why pair with someone?⌗
Being a remote worker often means working alone. Pairing is a fantastic way to get some time to socialize with a co-worker like RealOfficePeople™ do. I also don’t learn much from reading Pull Requests, release notes, or raw code compared to the times I’ve collaborated with other people.
Another advantage for pairing outside of your role is to learn more about the processes and experiences of parts of the organization you don’t work in day to day. If you’re an engineer and you pair with someone from tech support to help improve some of their internal process you’ll learn about perspectives and problems that otherwise might not be apparent. I’ve found that the more teams I work with the better I understand the bigger picture of what we’re all working towards.
Enough theory, let’s talk practice⌗
I look at pairing through the lens of “How many hours can I do this a week?”. In other words, I have roughly 40 hours a week spent working on things for the organization, so how many of those hours could I stand to devote to pairing with someone else? This is a personal question and one you should answer for yourself.
Once I’ve found how many hours I can spend I tend to divide that number into 1hr blocks. I find pairing for a minimum of 1 hour helps to make sure there’s enough time to really get into whatever topic the person I’m pairing with wants to cover. Often I’m likely to run over an hour rather than under, so an hour feels like the right minimum.
I always leave headroom for the time I have for pairing. As an example if I decide I’m going to spend at most 6 hours of my week pairing with folks I make sure never to schedule more than 5 people. This means when sessions run over I don’t go far beyond the overall budget of my time. I also try to schedule pairing sessions without anything coming directly after so that they can run over the minimum 1 hour without consequence of having a hard stop.
How to have a successful 🍐 sesh⌗
Have an “Ideas” document!
I’ll share a very basic template you can copy for yourself here:
The general idea is you create a shared page titled after your name and the person you’re pairing with and share it between the two of you. From there you just collect a list of topics of interest.
Commit to it⌗
For the people I pair with I default to a weekly time that works for us where we set a re-occurring calendar event. This event repeats forever and we both can make modifications to the event. I think regular pairing like this works best when both people commit to it.
…but remain flexible⌗
Life happens. Sometimes either you or the person you pair with won’t be available and that’s ok! When that happens just communicate as such and if possible re-schedule the session for another time that week. If you have to skip the week that’s fine too. It’s also possible you’ll find that a lot of the time there isn’t anything pressing that feels worth pairing on. Skip the week in that case! Or another idea is to have a shorter pair session reviewing your ideas doc together to see if there are things you both want to work on together that just aren’t written down and are easily forgotten.
Right now I’m not doing anything overly fancy when it comes to tools that help pair. My 🍐 stack looks like this:
- Video conferencing - This is a major 🔑 for pairing. All my pairing is remote and happens over video calls with screen-sharing. I’ve used Screenhero (RIP), Slack, Zoom, Screen.so, and MS Teams. If I had to pick the one that worked best I’d go with Screen.so, but honestly they all do a good enough job.
- My Calendar - I make heavy use of my Calendar (this can be anything, Google, Outlook, etc.) to schedule re-occurring pairing meetings and find open availability.
- A wiki - The aforementioned ideas doc lives in whatever wiki exists where I work. I’ve used Notion.so and Confluence primarily.
That’s really it. I don’t get too fancy with this stuff. If you have a Killer App or tool that really helps with pairing feel free to use it instead! My list used to be very specific in listing the exact product for each point, but I’ve found that products change and the basic set of tools remains the same. You need a tool to communicate in real time, a tool to schedule meetings, and a tool to asynchronously collaborate on pairing topics/backlog.
Keep Calm and 🍐 On⌗
Thanks for reading this and I hope it sparked some ideas for you. More importantly I hope it inspired you to offer to pair with someone or to ask someone to pair with you (feel free to link your peer/manager to this page if you need a conversation starter 😉).
There are few things I evangelize at work as much as I do Password Management/MFA. Pairing is a close second to that. Pairing is an investment you can make in yourself and the people you work with that pays immediate dividends in the form of increasing your knowledge and making your team stronger overall. So go out there and get your 🍐 on!
Liked what you just read? Go ahead and support more content like this by way of my coffee/beer money fund.