Pair programming is a software practice where two software developers will share one computer. The one with the keyboard is the one programming and is concerned with the details of implementation. The one without the keyboard is maintaining the bigger picture and the overall direction of the programming.

There will usually be a healthy level of discussion between the pair; the one on the keyboard will often describe what they are doing and thinking, while the other will be calling out the next steps and pointing out any issues.

It's a little bit like a rally car driver working with a navigator. The driver is responsible for focusing on solving the immediate problem, the handling of the car around the course. The navigator has the map, keeps track of their location, and ensures the driver has enough information about the direction being taken and any obstacles ahead.

It works well because the developer who is navigating is holding the bigger picture, which ultimately helps the developer who is driving to keep focused on what needs to be done to solve the immediate problem. The navigator is also able to spot potential problems in the design, and even simple things like typos, which will often go unnoticed otherwise.

When turning up the dials on good practice to the maximum for extreme programming, Kent Beck's view was that if we value peer code review so much, why not do it all the time? Extreme programmers will Pair Program all code that goes into a production environment. Pair programming is peer review on steroids.