Personally I think you need to interrupt coding frequently, for health and for cognitive freshness. When I've been tech lead, often the most heads-down devs produced the most problematic code if you didn't check in on them. My belief was along the lines of "if you don't throw away everything and start over at least once you're doing it wrong," with the idea being that coding too fast results in complex, un-elegant solutions. Finally, in a fast-paced environment, you simply have to check in with each other, and having to schedule meetings or calls just sucks. The team I'm in right now is not co-located and we're losing tons of productivity.
And yet. When I work at a remote location (not home but near-home, not at the main site), I get TONS more coding, research, writing, and shit work done. No comparison. The work I'm doing now is perhaps more amenable to sole-contributor stuff, but I recall in the faster-paced jobs this was also true.
It seems like flexibility is needed. Open-plan is great, but maybe rotating offices would be good, where people can spend a day in them cranking some stuff out, and then come up for air for the rest of the week.
1.) I've been a developer (in some context, this also includes "startup founder", "tech lead", and about a year total of internships) for about 10.5 years.
2.) Private office for 1 year total (across 2 companies). Shared office for 1 year (2 companies). Worked from home for a total of 2.2 years (2 companies). Private cube for 1.25 years (3 companies). Shared cube for 1.5 years. Open-floorplan for 20 months (Google), and war-room (same team in a large, 5-10 person office) for 2.5 years.
3.) It's varied throughout my career. As a startup founder, I neither interrupt people nor get interrupted, since I'm working from home and am the only developer on the project. When I was a tech lead, I did literally nothing but get interrupted; incoming requests outnumbered outgoing by roughly 10:1. As an individual dev, typically I'd be interrupted about 2-3 times for every time I asked someone else a question (my preference is usually much more toward figuring out something for myself than asking questions...probably moreso than it should be).
I am mildly in favor of open-plan offices, and here's why: most of the interesting stuff is happening outside of your head. I'll grant that open-plan offices are a huge distraction, they pull you out of flow, and as a result, you will write a lot less code than you would in a private office. However, here's where I say something controversial: code is a liability, not an asset. The goal of a developer is to solve problems, and you will solve more problems if you know what the pressing problems are than if you just put your head down and code up what your boss tells you to. It really sucks to slave away at a masterpiece of technology for a year or two, and then find that nobody uses it because you weren't solving the right problem to begin with.
Here's another statistic: in those 10.5 years of experience, I've implemented 30 projects (as in, working code delivered to boss/cofounder/teammates/market). Of those, 10 were successes, where I define "success" as either "used by > 1 million people", "at least 6 internal teams use it", or "made money for employer". The successes included 2 shared offices, 3 warrooms, 2 shared cubes, 2 open floorplans, and 1 private cube. The failures included 5 private cubes, 2 private office, 2 shared office, 7 open floorplans, and 4 works from home. (Interestingly, this seems to reproduce what I've heard in the literature of "same team in an office" > "private office" > "unrelated teams in an open floorplan".)
I'm curious, do folks in favor of private offices consider a project to be successful when it is delivered according to spec to your boss? Or is it successful when it makes it to market and makes a profit for the company? If it's the former, that would explain the differing views right there: it's quite possible for private offices to help you efficiently produce the wrong product.