This is part three of a four-part series on How to Become a Better Pair Programmer. If this is your first time landing on the blog, we suggest you catch up on part one and part two of the series first.

Overcome imposter syndrome

Impostor syndrome is something that plagues all of us from time to time. People who suffer from Impostor Syndrome experience periods of inadequacy and self-doubt even in the face of information that indicates the opposite is true.

If you feel like you’re an intellectual fraud when it comes to your work, just look at how many years of experience you have and how many successful projects you’ve been on. Your experience speaks for itself. You have to remember that you are much better than you think in your darkest hours, and you have a duty to share the wealth of information you’ve gained throughout your lifetime.

To overcome Impostor Syndrome, you should try to shift from a mindset that focuses on performance to one that focuses on learning. Not only will you then feel more free to experiment and be creative in your code, but you will also be able to infect your pair partner with a positive, can-do approach to software development.

Use tact

If you don’t have issues with self-doubt, then remember that tact is very important when working closely with someone for an extended period of time. You don’t want to steamroll your pair partner, not just because you don’t want to harm the relationship, but because you might also miss out on an opportunity to learn something new from them.

Of course, this tact has to be tempered with a willingness to advocate for your point of view, based on your experience. If you already know that a certain gem has conflicts with the version of Postgres you’re using, or that a proposed API has proven buggy in the past, then don’t be shy about sharing that information. You will save yourself, and your pair, a lot of headache in the long run!

Know which hill to die on

A big part of effective interpersonal communication is knowing which “hill to die on.” You don’t have to win every battle to win the war, and if you dig in deep on matters that, well, don’t matter, then you’ll drive a wedge between yourself and your pair partner for no gain.

I worked for an employer once where there was a deep divide on whether to use the hashrocket or JSON style for hashes. The team was split pretty evenly down the middle on the issue, and all of us were dug in pretty deeply. Whenever we needed to work with someone from “the other camp”, it was fraught with tension and difficulty, because the issue had become personal. In hindsight, that was a dumb thing to fight about. There were much larger issues than standardizing on a single point of syntax.

Know your limits

The flip side of advocating for your hard-won knowledge and experience is admitting your ignorance. There’s almost nothing worse than someone claiming to know what they don’t. It makes you an obstacle to finding real solutions, and it lowers your overall credibility. “I don’t know, but I bet we can figure it out” is a perfectly reasonable response.

Of course, nobody likes to look like or feel “dumb”, but that is the reality of our career choice. There is so much to know in a field like programming, and no one can possibly be fully versed in it all.

Add to that the ever-changing nature of technology and software development in general, and you get a sense of the challenge of “staying in shape” professionally.

The good news is that your employer – and your pair partner – aren’t expecting you to be all things to all people. Your job is not to know everything, but to be able to figure things out as the need arises. It’s okay to lean on your peers, Google an error message, or noodle around with a new gem so you can be proficient. It’s expected, even.

Coming up in Part 4

In the fourth and final installment of How to Become a Better Pair Programmer, we’ll look at knowing what role to play in a pair. Depending on whether you’re the more senior or junior developer of the partnership, you’ll want to do things according to your experience level.

Other parts of the series can be found below:

Part One - Tips and advice for creating a cohesive collaborative development environment

Part Two - Getting realistic and assuming the best

Part Three - Knowing your limits

Part Four - Knowing what role to play and when