Our dev culture discourages anyone working in "the zone" because more often than not, it produces crappy code -- crappy mainly in that it's hard for others to understand/maintain. If you're off by yourself thinking about something really hard, you're doing it wrong. You should be hashing out new ideas in conversations with other devs. Grab a conference room if you're conversation gets animated or regards something with a very narrow scope that others won't care about, otherwise do it in the open so anyone can jump in.
"Disruptions" are conversations where ideas and implementations are fleshed out. That's the hard work. Coding quietly means you're doing something so trivial that pairing would be silly.
I really believe this dev culture produces fewer defects and makes the team more responsive since so much knowledge is shared.
You obviously have little idea of what it means to be "in the zone." It is just as easy to get there with a pair as without, provided you have a decent environment to work in. Pairing is like tennis, another activity which can get you in the zone.
Your environment sounds to me like a typical too-many-chefs situation, and those environments usually tend to turn out mediocre crap fairly quickly, when the tasks are trivial, and to take forever to get something working when the task is complex and everybody needs to get their two cents in on how to do things.
Our team has very good chemistry, lots of respect for opinions all the way around. So I don't think people feel the need to get their two cents in on every issue. If a subset takes off on something, the rest know that they'll be brought up to speed at some later point, and the code quality will be decent. If there are parts of it that aren't decent, we'll either agree to fix them, or agree that we don't have resources and we'll have to live with them.
Regarding definitions of "in the zone", mine wouldn't include a pair in a good rhythm. Being in the zone, to me, evokes a lone programmer writing lots of code while holding complex mental models in his/her head for hours at a time. It's a pleasurable feeling for most of us with a bent for logic and problem solving, but my experience is that it doesn't always produce the best code.
I'm curious, what exactly kind of software do you work on? I suspect your approach might work okay for fairly simple apps where the main question is getting the requirements right, but not so much with anything that requires serious thinking. Or maybe you're just all a bunch of extraverts.
Yes, fleshing out requirements is a big part of it. Our apps are web apps but in financing, so they're not totally trivial. We do both the public facing web-apps and the tool used by loan processors for administration.
Our team has a high number of extraverts, but the introverts seem just as happy. We have no surly curmudgeons.
When I hired on, I was surprised that so many people rode bikes to work. And when I proposed climbing a local mountain to one similarly outdoorsy co-worker, I was surprised that the whole team was interested. 10 out of the 12 in the office either did the warm-up climb or actually camped out overnight and completed the larger climb (Mt St. Helens). I found this amount of shared lifestyle/outside-interests to be unique among places I've worked. I'm certain we weren't hired because of these interests, but it seems to have worked out that we share a lot of them.
> I found this amount of shared lifestyle/outside-interests to be unique among places I've worked. I'm certain we weren't hired because of these interests, but it seems to have worked out that we share a lot of them.
Well there you go then.
I can't say for sure, but I'm going to ask you to consider a possibility: either consciously or not, you have a hiring process that filters for "people like me". For instance, if your team was interviewing a fat person, somewhere in the interview process either you or the candidate would get a strong sense that they wouldn't "fit in" or they wouldn't be a good "cultural fit".
It's no skin off my back whether you hire fat/unoutdoorsy/introverted people or not, unless I'm applying to work at your shop, but it seems like you're deliberately creating a rigid monoculture, and rigid monocultures are prone to groupthink. You're doing everything you can to squash diversity (not in the "women and non-white people" sense, but in the "people who genuinely think differently" sense). If you do that enough, then even the people you have will suppress any "heretical" thoughts they might have. Maybe the gains in cohesion are worth it for you, maybe not; I have no way to tell. But it frightens me a little when places deliberately design themselves to induce groupthink.
Interesting. I was trying to think of any controversies due to "heretical" thoughts. We really haven't had any. (So maybe you are right!) We have our nerd-fights about say, rspec vs minitest, or estimating techniques, but not much beyond that. All of us lead pretty well, when we need to, and follow well when someone else is leading.
The Agile mantra these days is write code instead of talking, but there's no faster way to iterate than to have a conversation. Sure you've got to write code at some point, but save yourself wasted hours and days doing the wrong thing and talk about it for 30 minutes.
People seem to forget that code is a means, not an end.
P.S. Down-voting the OP for having a different opinion, for shame Hacker News.
On re-read, I'm guessing the down votes are for tone. It reads a little rigid and preachy to me now.
What I was attempting to describe is the mindset our team currently has, not what yours should have.
Our particular team of 8 devs is happy and productive with it. I do understand that this approach could be less than ideal for a different team, or the same team working on projects of a different nature.
Incidentally, our work space was designed by the team. We moved last summer. The management chose the office and we were given $50k to do whatever we wanted with it. We built one conference room, a server room, and two small meeting rooms. The rest was open with clusters of stand-up desks.
Your snark actually raises a good point: The optimal office arrangement probably depends on who works there.
Last Friday our team presented some of our dev proceses to the local agile group. We had 5 devs and a product person there. Someone observed that our team seems to have really good personal chemistry and we all agreed. We chalked it up to careful hiring. If you wouldn't function well with our set-up, we probably wouldn't offer you a job.
This seems like such an odd outlook to me, one in which you are effectively saying that no single indivisible task should or could ever be completed by a single person in a few hours of focused work.
Yes, we pretty much try to pair on everything. It doesn't work out when there is an odd number or someone gets pulled elsewhere, so it's not all of the time. When we don't pair, we do code reviews (also by a pair).
"Disruptions" are conversations where ideas and implementations are fleshed out. That's the hard work. Coding quietly means you're doing something so trivial that pairing would be silly.
I really believe this dev culture produces fewer defects and makes the team more responsive since so much knowledge is shared.