The trick is to make it so people have control. That said, I take issue with the claim people often make that all coding requires complete sound and visual isolation from other humans.

In my experience there are large swaths of software engineering tasks that involve transforming code that are not negatively affected by ambient noise and conversation, and that are relatively easy to context switch in and out of. I realize this probably is heresy to some people but it is the reality I find for myself. That does not mean there are not also large categories of tasks that require dedicated focus and isolation, but I take issue with the claim that all coding needs to occur in a sound proof chamber.

Some concrete examples:

- Fixing or writing unit tests

- Performing (low risk) operational + maintenance tasks

- Refactoring

- Design tweaks and improvements

- Deployments

- Building simple features

- Reviewing code

I find myself (and I'm sure many others do) doing these types things in an office environment that often has some ambient conversational noise and do not feel it negatively affects my work to the point where I decide to put on headphones. And no, I'm not talking about a case where someone is yelling in my ear or someone is blasting death metal behind me. I'm talking about a normal open office where people are generally respectful of each others' space and conscious of distractions.

It's great that you don't find conversations distracting, the problem is that others do. The best solution is to offer a work environment that both meets yours and their needs. An open office environment is death to productivity for lots of developers, they don't have the option to shut a door. It simply doesn't and can't work for a large portion of the work force.

A single person office environment is more productive for almost everyone. But it doesn't have to be forced on you, for example there is no reason why center areas can't be left open for those that prefer them.

But in reality the best way to collaborate is to do it in pieces. You come to my office. I come to yours. We invite the team to a conference room.

Yes, note my first sentence "the trick is giving people control." I was countering the commonly held view that for all people, all the time, no coding can be done with ambient noise. This was the claim of the post I was replying to "If you are constantly expected to be able to 'overhear' conversations while coding, I don't see how you could get anything done."

I doubt they meant literally anything. It's a common idiom. Also, a conversation that's loud enough to understand is more than just ambient noise.

Let me add a third perspective: like you, I have no problem doing those tasks in some light talking in the room. But the reason is because my brain is quite effective at completely shutting them off. Unless you directly address me, I can be right by your side and not actually hear a word you said to someone else. Hence the benefits of overhearing are completely lost on me.

Meanwhile, when I actually need to fully concentrate, even music can be distracting, so there's loss and no gain.

Most people need to concentrate on their take, especially the ones you mentioned. Code reviewing is difficult as you have to look at what the other person is doing, and on the fly try to understand it, unlike the code you've been writing on for sometime Unit tests sighs have your undivided attention to make sure you are making the test directly and that you aren't missing anything. It might be easy for you, but not for others