Somewhere in a closet in Texas, a desk sits, isolated from the noise of children and clanging dishes. From here, I gather my wits and connect to the outside world. I reach out to other devs.
Living in a Remote World (sortof)
For over 4 years, I’ve worked remotely. During some of that time I was part of a small company where I was the only employee (and only developer on the project). It gets lonely in a closet. But more than that, I just started getting weird with my coding. I let stuff slide that I knew nobody would ever read. I forgot or could no longer recognize best practices. I was receiving no feedback.
And that is a dangerous place. So I began to actively seek out people to pair with.
And pair I did. I paired with seasoned pros and lots of great junior devs. I met future coworkers and made connections that landed me future jobs. I also just learned new ideas and especially learned about new tooling and new ways to approach problems.
But I don’t think everyone is quite so into pairing…
Pairing–that’s SOOO 2011
I know that pairing may be a bit out-of-style as of late. It’s difficult to do remotely and definitely takes a social toll on people (even extroverts). Being sensitive to introverts as well as just recognizing that not all problems are solved well with a partner are at least two reasons why the community isn’t as gung-ho as it used to be about the practice.
When pairing with others, it’s best to take into account both who you are pairing with as well as the problem you’re trying to solve. Different pairing types have different pros and cons. While pairing with coworkers and random twitter followers over several years, I’ve mostly categorized my sessions into the following buckets:
Architectural
With coworkers, and at the beginning of a project, it can help to actually talk out the big picture of a project. You may not think of a big picture discussion as pairing, but I’ve found it pushes me past mental roadblocks and can keep me from heading down the wrong direction, which is much of what traditional pairing does.
Primary attributes
- Discussion about Architecture or overall direction
- Talk out ideas to flesh things out before implementing
Pros
- Great for getting on the same page
- Simple way to make sure your approach to a problem is sound
- Excellent way for leads to guide devs without it feeling like micromanagement.
- Code may not be involved at all
Cons
- Can feel a bit more like a 1:1 or a meeting
- Code may not be involved at all
Exploratory (try out the beginnings of an idea)
No matter what kind of project you have, exploratory pairing can really help push an idea along. At nearly every job I’ve had since 2008, I’ve participated in exploratory pairing and seen the benefits. When I worked alone, I asked a friend to sign an NDA so that I could pair with him while trying to get a proof-of-concept out. Highly useful in many situations.
Primary attributes
- Big chunks of code
- New project, potentially little testing
- Focus on discovering feasibility
Pros
- Pushes ideas forward and removes mental roadblocks easily
- Since it’s fast, doesn’t feel bad to write bad code and throw it away
Cons
- Difficult if the pairers are mis-matched or don’t fully understand the problem
- There is a definite upper bound to the size of the problem that can be explored
Code Review (instead of coding during, walk someone through code)
There’s a saying in the internet age that a pull request’s comments are indirectly proportional to its size. I’ve released pull requests with 5 lines of change that have 9 or 10 comments. I’ve also released pull requests with 900 lines of change that have ‘LGTM!’ – sigh – sometimes it’s better to walk people through your code so they can grok it and ask questions based on your logical order of explanation rather than the alphabetical order of files in a diff.
Primary attributes
- Code already written
- Walkthrough by writer with commentery or questions by other member(s).
Pros
- Allows for easier review of complex pull requests
- Lets the writer walk through the code logically rather than by file
- More robust review of code
Cons
- More time consuming than code reviews in some scenarios
- Requires the reviewer to have lots of confidence and the code writer to have a great deal of humility (even more than normal code review processes)
Ping Pong or Driver/Navigator
When I wanted to reach out to other devs I didn’t know well, I instinctively went for these styles of pairing. No other method is as easy to understand and it is great for helping more junior devs. If you’re at a company who hires less experienced devs than you (which you should be), then teaching them through pairing is an incredible way to invest in their future and the future of your company.
Primary attributes
- Small(ish) problems, solutions that need to be refined
- Tests + Code
- Accountability
Pros
- Great for back-end work and complicated but contained logic
- Moves a complicated task forward
- High focus on quality
- Knowledge transfer to colleagues who are less familiar with a section of code.
Cons
- Slow overall pace
- Needs devs with similar levels
Moral Support (deployment, support tickets, new tasks)
There’s so many times I’ve been scared to deploy. It’s a production environment that serves millions of people! Making a change you thought up a month ago and really hasn’t been as rigorously tested as you’d like is nerve-racking! So having an experienced dev on the line to ask questions and keep your cool can definitely help.
Primary attributes
- A major deployment or task needs to be carried out
- An experienced co-worker watches over another worker’s shoulder to provide support should the need arise
Pros
- Great for complicated deployments (someone can look at monitoring while someone else watches logs)
- Allows someone to do a difficult task with additional confidence
Cons
- Can be a mild waste of time for the supporter
- Can make some devs overconfident to a fault.
Applying Pairing Remotely and to Strangers
Pairing has value. It’s not easy, though. And it’s definitely not easy to pair with strangers–whether that’s new people at a job you have or random twitter followers; You’re putting yourself out there, after all!
I started by tweeting a lot about pairing. And using the #pairwithme hashtag. I added times on my website in the evenings that I was open for pairing. I found a handful of useful tools like ScreenHero and tmate. I solicited other’s input. It was sometimes scary. Some people that I paired with were SO GOOD at what they did that I was incredibly intimidated. But I learned new ideas from them. Some people became friends I still know today–and that would have never happened without me putting myself out there.
Let me tell you one story.
I met an amateur dev who had taught himself ruby and vi over the course of about 4 years and was using code to help his employer. We paired, we had a good time, and we resolved to pair again.
And so we did! This time, he showed me a bunch of vim shortcuts and tricks he’d learned and I helped him refactor an open source project he’d been working on. It was great! I loved that session. So we continued developing the relationship, pairing every month or so for a while.
When I took a job at a place who only hired remote employees and we needed to hire a new dev, I enthusiastically recommended him. He ended up getting hired and did a fantastic job for the company.
When I got laid off, his connections from pairing got me my next job, here at Stitch Fix.
The Good of Pairing
Pairing won’t always get you your next job, but it might make how you do your job better. It might improve both your code and how you communicate with other developers. If you’re willing to pair with people outside your company, you might be able to find exceptional developers that tell you more in a 1 hour, no-pressure pairing session than in any interview.
Pairing isn’t a magic pill. It’s taxing. It pushes you. It gets you out of a comfort zone.
And I highly recommend it.
