I do work on writing novel code, that is multithreaded, and sensitive to performance. Maybe that is better suited to solo development. That's a separate issue from personality. Some people seem to thrive with more collaborative forms of development, some wither. I'm struck by that distinction every time there is an HN discussion of pair programming.
Yes, exactly. Unfortunately, every so often you get these companies that take on a process as "part of their core culture", when culture should be about principle, not process.
By taking a practice as a core value, they are implicitly stating that it is the One True Way to do things, which means that anyone NOT doing it the One True Way is doing it wrong (to the point that they refuse to hire anyone unwilling to toe the line). I wonder how these people would feel entering a company whose One True Way is waterfall development? Because up until a decade and a half ago, that WAS the One True Way.
One thing you should definitely be careful of (not sure if you do this or not) is requiring adherence to a process that demonstrably doesn't work for a sufficiently large percentage of the population. As another poster pointed out, they select against people who don't like to pair program, which cuts out a large percentage of the (good) developer population, thus fostering monoculture.
Agreed. The "open dev time" idea is attractive, and I can imagine developers getting excited about it, (or at least developers who enjoy doing side projects). But it doesn't seem to address kstenerud's point.
In our interview process, we want developers who like writing software, and want to improve. Asking about side projects, software topics they're researching on their own, languages they're playing with, seems to be a useful thing to focus on. Or at least, I tend to like candidates with good answers to those questions. That's a monoculture I think I'd actually like.