I’m new to pair programming. While the concept of pair programming is certainly not new to me (see among many, “The Clean Coder” by Robert C. Martin), I admit I previously did not have many opportunities to actually pair. It was either foreign to others or they just “didn’t buy the concept”. It is the reason I consider myself a complete newbie to the subject — perhaps not regarding theory, but certainly regarding practice. I joined madewithlove roughly five months ago and I got quite excited about the pair programming encouragement in my teammate’s articles on our company blog:

My goal here is certainly not to advise how to pair program (many have already done this well, including Wouter), but rather self introspect and describe what goes through the mind of the programmer when they are still new to pairing. If you’re a beginner to this, I hope you’ll be able to easily relate.

Fear of judgment

I’m fairly certain that when you’re first asked to pair program with your teammate, the first thought that goes through your mind is “I’m not sure if I’m comfortable showing my programming Kung foo live to somebody… They’ll immediately see the mistakes I make when I struggle to come up with a solution on the spot or when I can’t recall some helper method I need. Let’s put it more bluntly: the thought of pair programming for the first time can be terrifying. I’m also fairly certain many of the readers are familiar with imposter syndrome, quite common in the fast-paced IT world.

The fear of judgment was the first feeling I had to fight. I try to be a rational human being, so that was fairly easy to overcome. I concluded that we’re here to do work and worrying about any shortcomings one may have is less important than getting the job done. Plus, without too much self-appraisal, I think I get the job done pretty well when working solo, so why should I worry about being judged? If I’m already part of the team, I’ve most certainly proven I’m good enough to be here in the first place. Be rational. 🙂

It’s like code review on steroids

Think about code reviews of your pull requests. Do you consider them judging your work? Judging sounds quite personal, not at all professional. Sure, there’s some nerd type of jokes going around — “Aren’t code reviews judging your teammates anyway? Haha” — they’re just jokes. That’s the point. We make fun of ourselves sometimes; it’s healthy. Just as a code review of your pull request is an opportunity to not only catch bugs but also improve the quality of your contribution and means to learn, so is pair programming!

“Aren’t code reviews judging your teammates anyway? Haha“

I won’t get too detailed with the advantages of pair programming (see the articles linked above). However, when there are two pairs of eyes on the same lines of code, there’s definitely a higher probability you’ll catch bugs on the spot, your contribution will most certainly be of better quality (as there’s two of you working on it together), and finally, you have the opportunity to learn as you go, instead of waiting for those (hopefully valuable) tips you get after the reviews of your code are completed. On that note, your PRs will probably blaze through code review as well!

Getting help while pairing

Reference documentation

  • I’m Laravel Certified Developer and I certainly don’t know everything or even most of the Laravel API by heart. A good IDE may help with auto-completion, but it’s okay to reference documentation! There’s also a chance your pairing partner will know. Nobody expects you to know the API by heart.
  • SQL databases are not a foreign land to me, but I may not immediately know how to make a recursive query or what’s the foreign key name length limit, but it’s okay to reference documentation! Guess what, your pairing partner may know how to create that query you need or how your query may be exploited. It’s good to have a second pair of eyes on your code.

Do a Google search (o hai, StackOverflow)

  • It’s okay to admit you “don’t know” and search for an answer. When I work solo and something is taking me longer to understand or figure out, I start with a Google search. No hits? I have an A-team to back me up. When I pair, I just say “I don’t know” instead of fumbling and trying to look like I know what I’m doing/looking for. Your pairing partner is there to help you. They may sit silently, not wanting to interrupt when you code, but they will help when you hit a wall and struggle. You’re a team and, above all, being honest is really the best you can do.

These are some of the things I do when I work. And you know what? Your pairing partner does, too. So get over yourself and make the best of the opportunity to pair :).

There’s more than code to it

Pair programming is a cool opportunity to see how your teammates work. Not only may you see a cool IDE feature or a convenient BASH alias that will speed up your own workflow but you can also share how you work and let your partner in on your own toolkit kung fu. This works both ways, so it is nothing less than an opportunity to learn.

Plus, if you work remotely, like most of my team at madewithlove (we’re hiring!), you have the opportunity to get to know your teammates better on the personal level (pairing can be exhausting, you do need those short breaks!).

Opportunity

I consider pair programming an opportunity, an opportunity to learn and become better. I put that over any fear of judgment or imposter syndrome, because, as we all know, both are usually self-inflicted.

Want to read more about pair programming?

We have recently written quite a few posts about pair programming. Is it worth for your team? How to keep it digestible?

How can madewithlove help?

Madewithlove offers software engineering as a service. Not only do we create great software for our clients, but we also help you scale or refactor your current projects. We like helping other developers out and leading by example.  If you’re struggling with technical debt – let us help you fix that, in cooperation with your own team, so you can finally launch new features again.