This post started as an internal document written by our Senior Site Reliability Engineer, Joe Purdy. In it he describes his personal approach to pairing (including, but not limited to, pair programming). We hope this helps you in your own work, whether or not you’re an engineer.
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.
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.
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.
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 one hour blocks. I find pairing for a minimum of one 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 six hours of my week pairing with folks I make sure never to schedule more than five 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.
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.
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.
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:
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.
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!