Time Well Spent

Over the past six years of practicing different types of programming, I have worked in a variety of environments. I’ve seen traditional and non-traditional, organized and not so much. However in the last 2+ years being remote and also part of a big team with great people that love to pair-program, has made me realize that there’s one particular style that just rocks and that’s pair-programming, let me tell you why you will think the same.

What is it?

Pair-programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

Let’s keep this down to earth. Imagine you’re driving a learning car through your city. The driver is currently using the keyboard and mouse, while the teacher is dropping helpful hints, course corrections and helping the driver along the way; he can even take control of the car once in awhile, to make the driver see something done before he can understand how to do it. But it’s not the only way to do it.

Pairing styles

There are various styles of pair-programming. All styles are valid, but I have a preference for the method we use and you’ll see soon why.

Driver-Navigator

This is the most common method of pair-programming, to the point where I believe this is what people think pair-programming is, it consists of two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair).

The driver at the keyboard, and the navigator actively involved in the programming task but focusing more on overall direction; it is expected that the programmers swap roles every few minutes or so. But this style of “pairing” can lead into an awkward situation.

This situation is caused by developers that are not interested in different technologies that are commonly used by the same team and leads to the navigator being distracted or doing different tasks not related to the development work currently being done. Another common cause for this is when people are not great at communicating their thoughts and want to develop an idea, so the driver proceeds to code silently for an extensive amount of time, which can have the effect of boring the navigator who naturally continues to check his or her phone or some other non-code-focused task.

Ping-Pong

There are a couple of ways to use this method, but the basics are, both members write code frequently. Because of this, the stress of the importance of having two sets of active input devices become critical.

The first way is where one member takes the responsibility of writing all the tests for the pairing session time and the second member is responsible for getting them to pass.

The second way of doing the ping-pong style is where the role of “test creator” passes between participants. This is done by having the first member writing a test, then control goes to the second member to turn it green, then responsibilities immediately switch for writing the next test.

The primary difference between these two is that in the first form, the roles are stable, but control is passed. In the second both position and control are passed. We use the latter, which is an efficient and excellent way to introduce people to pair-programming — let me tell you why.

There’s also a variant of this style, only pairing when needed, which we also do. Developers need/want a little uninterrupted alone time. Sometimes when you’re coding, on the right track, and know where you’re going, you just need to concentrate in a silenced environment and get stuff done. It gets hard to get into the state of doing things when there’s someone on your side, watching your screen and talking to your ear.

Being a mentor

Developers shouldn’t be faced with a wall when stuck on a problem. If you’re struggling, there should be someone in your company you can reach out to and ask for help.

And that’s why we are encouraged in our team to prioritize pairs that have experience in different topics (for example, Backend and Frontend) to make the learning curve and expertise joyful. As a pro tip when you’re looking for a new job, always prioritize teams that do this. It’s extremely common to find dev teams that value velocity above everything else, and that can stunt long-term growth. Pairing to gain experience from partner’s strengths is what makes the whole experience so powerful. There’s a great article a by Eric Elliot about building balanced development teams if you’re more interested in the management side.

Practical tips

1. It’s all about the bandwidth when you’re remote, both ends need to have a great download/upload speed.
2. One of the best apps for working remote is Screen Hero. If you can’t get an invite, don’t worry, there are plenty similar tools around and you can always use Google Hangouts.
3. For folks that pair in the office, your employer should get your screens with the same quality/resolution, I believe this is very important to have the same conditions when looking at a problem.
4. Don’t feel bad for asking help when needed, Be open and receptive to it. Pay attention and follow along.
5. Avoid distractions, turn off notifications, especially if you’re the one navigating.
6. When pairing with someone that has less experience, let them drive. People learn better by doing. They’ll remember how to do it the next time they’re driving.
7. Before diving into a problem, discuss it with your teammate. You want to cooperate and get both perspectives before writing anything — what do you expect to happen, what would be a problem if it’s written in such a way, etc. You have 2 developers, 2 minds, use them.
8. Feeling confident in one area? Try doing it alone, It might not be always right, but you can learn by being challenged. Be proactive about it.

The end result

Our team is composed of lots of great developers that are great at most things and superb at others. To me, it’s the perfect answer to why my moral is always high. When you’re not confident about a reply, your teammate might have a solution for the problem, and talking about might just be enough to trigger a breakthrough. This is a huge benefit for the company that comes with this philosophy in my opinion.

I’ve written some of my best code when pairing because most of it was written with two people’s hands on a keyboard together.

These benefits are why I encourage you to try pairing or to ask your management team to consider it. You would be amazed at how much your productivity will be increased by never hesitating to ask for help and by mentoring others.