No, not every company uses it, nor is it good for every company or circumstance. It is just a smell that the developers do not believe that working with someone else will help them increase their quality or speed. Some developers really are fast enough that it would slow them down to pair, but then generally, their slower team members might be hugely benefited by just a few hours a week of pairing. So it is a trade-off, do they go fast alone, or go pretty fast with a partner, and increase the _total_ productivity over time?
Pair programming is a great way to get new developers up to speed with the code-base, but the team that is going to be using it long-term needs to apply it with discipline.
As for hardware setup, the best I have used is: machines with cloned monitors, two mice, and two keyboards, both side by side so the developers can talk in low tones and not bother anyone else. I do this now at work, and it is a lot of fun, and it really averages to be that we get done more than twice what we would work normally alone.
My experience: pair programming usually degenerates into having a human version of the annoying syntax checker prevalent in previous versions of Visual Basic, which required you to close the dialog and then fix the error before allowing you to move to another line. "Whoops, you forgot a semicolon there." "Are you going to close that open brace?" YES I'M GOING TO CLOSE IT I WAS GETTING TO THAT ASDFGHJKL;
That honestly does happen at first, until you get used to the other person a bit more, then the real speed happens.
Once you really are switching every few minutes, and you learn to trust the other guy to figure that crap out himself, then you can stop watching his semi-colons and start watching ahead for what you are going to do when you get your turn to drive. I have worked with someone like that, and the effect was profound, we would get done sometimes 4-5 days of low bug count, high quality work each day. You have to learn to disengage just a bit and start actually thinking about how his work fits in the big picture, and what you are going to do next, not his spelling errata.
IMHO that's either the navigator not knowing any better, or wishing he was the driver, or just being a jerk. The navigator's job isn't to focus on the nitty-gritty, that's what the driver is doing. The navigator should instead, since he's free to think more and look around, keep his eyes on the bigger picture. If the navigator is more skilled or experienced than the driver, then the navigator should be that much more patient and respectful.
