We are used to do programming sitting alone, put headphones on, and just immerse in it. But it does not have to be that way always. You can grab one of your friends or peer to sit next to you and you both can start coding. It sounds weird, two people sitting next to each other and working on the same problem. Isn’t it?

It is not. At times you need to just need to share your views with your peers and see how different they think about the same problem. I have done it a lot in my day-to-day work. One of my friends, Arvind — https://medium.com/@arvindp94 , whenever we are bored or we think we need more inputs from some other person, we used to sit together and solve the problem. Don’t confuse only one person types, the other person involves in discussion and other stuff.

I will walk you through some of the advantages of doing this exercise now and then. Let’s go!

Know mistakes

We just take for granted the implementation we do. When you start discussing with your peer, you understand the mistakes you do on regular basis. For example, you might have missed edge case < instead of <= this will either gets pointed out in the review cycle or the worst case is that it just goes into production.

These mistakes can be as simple as above or can be very high-level stuff like why do we need to create this particular X function? Is it absolutely required, etc. The discussion you do with your peer gives you a lot of information than just identifying the mistake.

Brainstorm

Programming is not just sitting in front of a computer and writing some code that follows syntax. At times the discussion just goes out of control so much that we end up grabbing a whiteboard and marker and drawing the components and relations etc. At this particular point, drawing alone just doesn’t make sense.

With your friend, you have some counterarguments, you tweak the design and ultimately you make it an efficient version. This is the best thing that happens with peer programming. Brainstorming some particular problem in deep gives more information on how it should be implemented.

In any stream, working in a silo without discussing what you are doing with someone who can criticize, is never going to give the best output

Code structure

This is the fun part of the discussions. We used to get into arguments why a particular function or a variable should be called in that way. These are the low-level building blocks of the code. It doesn’t stop there, it goes to what should be the inputs for a function, what should it return, how to structure the project, whether to create a new file/folder for the components you are adding, etc. Few topics we mostly used to discuss

Naming
Input and outputs
Project structure
Better algorithms

I have separately explained how I structure the projects I work on here. Most of the things I mentioned there are learned from this kind of discussions.

Less review time and Better outcome

With all these discussions happening you mostly end up having a really polished and appropriate version of the feature/change you are implementing. This means the review cycles will take very little time as it is already screened and filtered.

Along with that, the entire process is real-time unlike PR reviews, which take a lot of time and multiple cycles.

Teamwork

This is another important topic that is non-technical. Applying two brains to one topic is not easy. You get into a lot of arguments at times they can go even worse. How you handle these situations is important. People who participate in any kind of discussion should be as transparent as possible.

Whenever we make a counterargument we should just target the argument, not the person. We need to understand that we are with a collective goal to make the feature/change more efficient.

So, make arguments with proofs are reasons. Be open to accept other views and approaches if you don’t have any reason to stick with your version. Don’t take anything personally and keep the discussions and arguments healthy.

More often programmers(myself) are good at coding than dealing with people which is not so good. So, doing more of these kinds of exercises will improve the skills required to work with a team and get the best output.

Summary

Pair programming is where two people program/code the same problem sitting next to each other(or a call with a shared screen). The discussions we do with the peer while coding will improve our technical abilities, bring the best outcome, and improve our teamwork skills.

So, find a perfect partner and try it out! I write similar tech experiences on Twitter. Follow me here — https://twitter.com/pramodk73