I would have thought developers are more likely to have put a lot of thought into how they're most productive. It's a bit patronising imposing something different on people who feel they've figured it out.
It's not really an imposition.
Many engineers like flexible hours and prefer to work for companies who like that.
Since we pair full time, it's not practical to have flexible start or finish times.
If anything, the "imposition" is committing to pair programming. Many folk don't like it, or don't like the idea of it, and never apply.
Lots of people don't like the idea of pairing by default.
I was skeptical about its utility, except as a way to learn.
But these days I find that I don't want to solo if I can help it. On days when I'm soloing I have to use more ritalin to manage my ADHD than on days when I'm pairing.
And when I'm not at the keyboard, the slowness of my pair and the inelegance of their code - it's hard to formulate the right nudges or wait for their cogs to spin and realise the issues with their approach.
I'd love to work with better programmers, but they're hard to find.
When I first learned to drive a car I couldn't talk at the same time.
Is it really useful to do it all the time though? Like there must sometimes be edge cases where people will achieve more alone, e.g. if it's something simple/repetitive, isn't it more productive to just hammer through?
So for repetitive stuff we often wind up throwing together something to do it for us.
Additionally, in Pivotal Labs, one goal is to teach the practice of pairing. It works best by total immersion.
By analogy, French teachers try to make the class speak French at all times, even if sometimes it's easier to speak a mix of English and French.