How To Be a Terrible Pair

I heard you got some bad news: your team lead is forcing you to pair on all stories. This sounds grim, but I have a few tips for you. Follow this advice to become a terrible pair, and you'll be back to working by yourself in no time.

Warming Up

First, make sure your form is correct. Practice leaning back and folding your arms. Fire up your laptop's camera to observe yourself—you want to emit the minimum amount of interest in what your pair is doing. Throw in a yawn or two.

Preparing the Workstation

Then, set up your workstation. Well, set up at your pair's workstation. Adjust your chair so it leans back as far as possible. You don't want to be too close to the keyboard when you start.

Keep your phone at the ready (you'll need to keep an eye on Twitter), and make sure there is space for your own laptop (you'll need this for watching videos on YouTube).

If you need extra space for your laptop, just get rid of the second mouse and keyboard! When you do need to write some code, you can just grab the keyboard from your pair anyway.

Picking a Path

OK, we're ready to start pairing! The intensity is high at the beginning, but don't get too worried about effort—you'll be able to coast for most of the process. Once you are set up at the workstation, it is important to express a very strong opinion on the architecture needed to implement the feature. Pick a side, preferably one in opposition to your pair, and argue vehemently for its merits.

If you win the argument, great! Pairing is really about winning. If you don't, that's actually OK too. When you miss your deadline, you can say "Well, I wanted to do it another way, but we went down another path and lost a lot of time."

Writing Code

After all this, it's time to code. Remember what you practiced—keep those arms crossed and let your pair do most of the work for the first few hours. If they try to interrupt you by asking for your opinion, respond with something like "What you've got sounds good," or "I guess that could work." Or, just grunt.

If your pair is struggling with what to do next, that means they are easily distracted. Quick, check Reddit!

Eventually you will have to write some code. Wait for an opportune time and grab the keyboard away from your pair. Move quickly and don't explain yourself. When you do get questions, respond in a condescending manner: "You've never seen this before?" or "This is pretty basic stuff." If they question your approach (especially if it's valid), huff and take it personally. Questioning an abstract idea is about as bad as calling your dog ugly or insulting a relative.

Once you've got some momentum, go ahead and take a break. If you want to be proactive, schedule meetings for the middle of the morning or the middle of the afternoon. Pairing is exhausting—it's better to break it up into 60-90 minute chunks anyway.

Finishing the Feature

Somehow—it's probably your pair's fault—the deadline is near and your story isn't anywhere close to complete. It's time to be a hero. Grab the keyboard (your form should be excellent by now) and start cranking out that code. Tests? We can add those later. Next week, maybe. Refactoring? Pssh, you understand this code. Everyone else should be able to understand it.

The important thing now is to finish the feature and throw it over the wall for QA to deal with. Push up your changes and—this is important—leave quickly after. The build might break, so you want to be out of there before the failures start to appear.

Living the Life

Congratulations! You've alienated your team members and made yourself intolerable. You can finally get back to writing code on your own. Now, that does mean when the build breaks they can pin it back on you. However, if you are territorial about the code you work on, it will reach the coveted "black box" status, where failures are common and no one wants to peek inside.

Converting to the Dark Side

Of course, you may not be able to dodge pairing forever. If these practices don't work for you, I suppose you could consider the benefits of pairing and how to be a better pair. It might in fact push you in ways you can't imagine and greatly improve your career.

Here's some reading, just in case:

Mike Jansen, Vice President of Operations

Mike Jansen has spent the past seven years in pursuit of quality, maintainable code in the world of software development.

Interested in 8th Light's services? Let's talk.

Contact Us