In my experience pair programming solve the problem more fun way and I enjoy it. it works for most.

Pair programming consists of two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on the overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so.

Common Pitfalls

• both programmers must be actively engaging with the task throughout a paired session, otherwise, no benefit can be expected
• a simple but often raised objection is that pairing “doubles costs”; that is a misconception based on equating programming with typing — however, one should be aware that this is the worst-case outcome of poorly applied pairing
• at least the driver, and possibly both programmers, are expected to keep up a running commentary; pair programming is also “programming out loud” — if the driver is silent, the navigator should intervene
• pair programming cannot be fruitfully forced upon people, especially if relationship issues, including the most mundane (such as personal hygiene), are getting in the way; solve these first!

Skill Levels

As suggested above one of the major issues preventing effective pairing is passivity. When used simultaneously with test-driven development, one variant called “ping-pong programming” encourages more frequent switching of roles: one programmer writes a failing unit test, then passes the keyboard to the other who writes the corresponding code, then goes on to a new test.

This variant can be used purely for pedagogic purposes, or by already experienced programmers as a playful variant.

• Beginner:
• able to participate as navigator, in particular, to intervene appropriately
• able to participate as a driver, in particular, to explain code while writing it
• Intermediate
• can tell the right moment to give up the keyboard and switch roles
• can tell the right moment to “steal” the keyboard and switch roles
• Advanced
• able to “drop-in” when another pair has been working on a task and pick up the navigator role smoothly

Expected Benefits

• increased code quality: “programming out loud” leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys
• better diffusion of knowledge among the team, in particular when a developer unfamiliar with a component is pairing with one who knows it much better
• better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members
• a large reduction in coordination efforts, since there are N/2 pairs to coordinate instead of N individual developers
• improved resiliency of a pair to interruptions, compared to an individual developer: when one member of the pair must attend to an external prompt, the other can remains focused on the task and can assist in regaining focus afterward

Me and my friends like Sougata, Shovan, Akash they are the good pairs for me, it really works for me to develop an algorithm or implementing an algorithm. It is the awesome technique for improving the quality of code and faster development.

So why are you waiting for give it a try?