There are a couple of dominant theories on developer workspaces, and which one you'll see at any given employer tends to indicate their general attitude toward programming.
The traditional model is to give each dev a cube, or an office, in which they can get their work done in solitude. There are advantages, to be sure; it's just you and your keyboard, so you can get "plugged in" more easily without needing to actively shut out the rest of the world. However, this approach tends to create "lone wolves"; coders who go off and code for hours and hours at a time in more or less a vacuum. The solitude can also be a distraction in itself for a lot of the personalities that are drawn to coding; when the isolation and sterility of your environment is very noticeable, it becomes its own distraction (or, more accurately, you tend to invent your own distractions to make up for it).
The newer theory is a more collaborative approach. Put coders in a common, open space that's easy to move around in. Encourage people to move, and they tend to do so, to pair up on a problem, discuss a design, etc etc. It's more of a "lab" environment than an "office" environment. The idea is to improve synergy by increasing the dev team's exposure to each other, while maintaining a focus on the job(s) at hand. In such an environment, it's still possible, and perfectly acceptable, to "tune out" everybody else; a pair of headphones hooked up to your computer (or cell phone or music player) is a very effective way to lose the distractions when you need to focus on what's in front of you.
My experience is that most companies are moving toward the newer arrangement of a team room with no walls. First off, it's what the more team-oriented coders want, and second, it's cost-effective; a few long tables is much cheaper to put into a room than a pre-fab cubicle system. However, in those environments, it's usually good to provide some empty offices as "private rooms". You go in there to answer a personal cell call, or if you need to hash something out with other team members vocally (personal or professional), or if you just need a few hours to close the door, put your head down and code (with laptops or a hosted-desktop environment being a requisite for this ability). The expectation for any of these, however, is that it is a temporary state of affairs.
In contrast to what I just said, my last job switch was from a more Agile-oriented environment with large, open team rooms, to a more traditional cube farm. While both of them took some getting used to, once I did I was productive either way. The difference was more in what I was expected to do; in the team room I was one guy out of a dozen working on the same codebase. In my new job, I've created several new applications with little or no involvement from other devs; collaboration is mostly by request.
