Do pair programming

What's better than writing code alone, with your favorite concentration music playing in your ears?

Coding with a pair that points out every time you make an error and keeps you from spending five minutes finding the best concentration music and fifteen minutes browsing your social media feed.

It might not be as pleasant as coding to instrumental rock, but chances are it's more efficient.

Understanding pair programming

Pair programming is when one person writes the code (the "driver") while the other (the "navigator") watches for implementation errors, considers the bigger picture, and, in general, keeps the driver on the road and ensures they get to their destination.

Swapping roles from time to time works even better. It ensures that the output includes the contributions of both of you, both as a driver and as a navigator, and makes the process less monotonous and tiring.

I especially like the TDD version of pair programming. One writes a failing test case and passes the keyboard to the other. The other makes the test case pass, writes another failing test, and then returns the keyboard. This guarantees a frequent change of roles and is also a lot of fun.

Why pair program?

First, it's the best way to learn and spread domain knowledge in the team and company. This is true both for the knowledge of the language, tool, or framework that you use and also the domain knowledge. This way, it helps break down silos* in the company.

Pair programming also improves the quality of the software. We're more likely to ship sloppy code if nobody is watching, and that is true even if the code is reviewed before shipping.

Why is that so?

Reviewers are more likely to pass on questionable code to avoid holding up its delivery and being the guy or gal with nitpicks. However, the situation is different when you're the navigator, as you can stop the sloppiness before it's born (and then have an active discussion about it).

Another advantage is that you are constantly being forced to focus by your teammate, so you're less likely to drift away and check all kinds of things that are not crucial to solving the problem. This can range from checking tech articles or immersing yourself in configuration options of some tool you use to scrolling social media feeds (and, let's be honest, it's more often the latter).

Pairing helps you avoid rabbit holes, which are easier to fall into when working alone.

When someone else is with you, they can offer an outsider's perspective. They can point out that your "I'm almost there" solution will probably not work, and even if it does, it won't be the most stable or maintainable solution for the problem.

Pair programming is much more intense than solo programming, so you'll get tired sooner. However, you want pair programming sessions to be fun and productive, so don't be shy to ask for a break if you need it ([[Take regular breaks | and you do need it]]).

What to pair program on

Some coding exercises lend themselves better to pair programming than others. Here are some that are great, but by no means this is an exhaustive list:

• The initial phase of adding a non-trivial feature
• Adding (or refactoring) complex logic
• Hunting down and fixing a thorny bug

The common in all of these is that having a second brain (they usually say a second pair of eyes, but brains seem more critical) focused on a problem makes us go faster and think of more things that can go wrong and should be addressed. When fixing a bug, two people can come up with more reasons for why the bug is there.

You can also ask to do pair programming when you feel you've lost momentum on something or suspect you'll need extra support from someone who can watch and help you.

Last but not least, if you're less familiar with an area (either the language, the framework, or a specific part of the app), asking for help from an expert can help you level up and gain familiarity—a familiarity that you can then pass on to others.

What not to pair program on

Tasks that are too easy or monotonous are not a good match for pair programming, and they can be done with an AI assistant.

The other task category I don't recommend pairing on is when long, sustained focus and thinking are needed, as you can't think deeply in pairs.

Overcoming the fear

It can be daunting to ask to pair and embarrassing to have someone watch as you fumble with editing code blocks and not know which array method to use.

Don't worry—you'll overcome the initial fear, and the time you spend pairing is well-invested, especially if you're a junior developer (and who isn't in certain areas?).

The fear will subside when you realize that even the most senior programmers make typing errors and must look up the signatures of common methods.

That said, it's undeniably scary to let others see your programming shortcomings, but this is one of those examples where pushing beyond your comfort zone makes you grow. Think of it this way: we all have weaknesses, and pairing is one of the best ways to improve them.

In summary

You should strive to do pair programming regularly because it has tremendous benefits.

• It makes the quality of the produced code better
• Someone watching you as you work keeps you on track and makes you accountable
• You learn from your pair about the domains they are more proficient in or about the tools they use and how they use them
• It helps you move ahead with complex tasks
• It can be intimidating to see how bad you are at certain things (or how bad you think you are), but pairing is a phenomenal way to learn and improve.

So don't be shy, and start pairing.

* A code silo is an area of the application that only a specific person or a small number of people know something about.