Pair programming vs autonomy

Pair programming has gone mainstream when you can read about it in gory detail in the NY Times:

Once two of our programmers had a falling out over a keyboard function. The navigator wanted to remap the caps lock key as a control key for when they switched roles.

Nothing ground-breaking here, but an example of the article's detail -- pretty geeky stuff. Soon, we'll be able to talk about the pros and cons of it with our parents.

I've never worked in a pair programming shop, and have always been suspicious about how well it would work.

My basic suspicion about it boils down to this: Dan Pink argues forcefully that the future of workforce motivation for creative professions involves granting lots of autonomy -- including locational and temporal. His argument is pretty convincing.

If people should be given the ability to choose their own work hours and location, how can pair programming survive?

Other agile practices can be constraining also, such as the daily scrum or a physical Kanban board, but none as deeply as pair programming. These guys have a daily 9 am meeting where they figure out who they'll work with and, presumably, what they'll be working on. Then they adhere to a fairly strict work pattern -- 25 mins on, 5 mins off.

The writer indicates all participants are pretty happy about it. I liked this article particularly because he went into such detail about their implementation at a personal level. Indeed, it sounded inviting to me.

But, I can't both be a fan of pair programming and also Dan Pink's research on motivation, can I? They seem inherently at odds.