Why do programmers need private offices with doors?

Asking quick questions in such an environment is also not that much of a disturbance because most people are working on similar features at the moment and there's a high chance that they don't need to do the whole context switch to assist you. It's really highly productive.

For the times where you really needed some time for yourself, headphones work just fine. I wouldn't want to wear them all the time as even the best ones become uncomfortable after few hours, but that's also not really needed in a small shared room.

Sorry for the adversarial tone, but "we should just force people" to me shows you deserve to be chastised a bit. First of all, you are not an employer (luckily), so there is no "we", each company decides for itself how to handle remote, and luckily, many have weighed on the benefits and have decided to go with that.

Second, the premise of you saying "oh come on, stop behaving like babies" shows to me that you think that "behaving like a baby" means:

- not wanting to waste an average of 2 (unpaid) hours of your day stuck in traffic commuting (which, by the way, is also bad for the environment)

- wanting peaceful and quiet atmosphere where you can focus on your work without noise and people tapping you on the shoulders

And I don't want even to argue with that, it's that bad of a take. Based on your views you are either young and full of energy (not having children), or old enough (boomer) and with people taking care of chores for you (wife) that to you it is the norm and we are all snowflakes unreasonably complaining. I don't see our views and incentives aligning on this.

> The number one problem I see at my work place is devs that are good at coding but that are very bad at even understanding what is the goal of the code they are doing.

That's just bad developers. They can't be good at coding if they don't understand the goal of the code, that's an oxymoron.

> Between a great coder and an average coder, the one who is good at being interrupted is a better dev. Coding in itself is just part of skill, but it is not the most important.

Doing good work, for which you require peace and quiet and a focused state of mind, is what being good at coding is all about. Also, most of the times it's better if a discussion is in a written form (e.g slack/PR/ticket) so others can use it as a reference in the future, rather than a chat you and Josh had at the whiteboard. Being a good coder also means being able to document well what your reasoning are, what your design is, and how to implement it, both things which require you to write it the HECK down.

> For me, you are the one who sounds like a toddler who asks everyone around them to be less efficient just because otherwise you are mildly inconvenienced.

The premise that everyone is more efficient with constant interruption and questions pouring from every direction, all the time, is laughable at best. There is ton of research that office interruptions drag down the productivity of the group, while all you have is some boomer's feeling that people are working better where they can observe them.

I started this response by saying I am sorry for the adversarial tone of my response, but the more I think of this now, the more I am not sorry. I see opinions like yours as a part of the problem why the rest of us can't have good things and a quiet and productive work life. If you want to go the office to get immersed in the beautiful, inspiring atmosphere of rows of desks with guys with headphones click-clacking away on their keyboards and discussing the last season of Game of Thrones, be my guest and go for it, but I am happy that the rest of us can choose not to.

https://www.psychologicalscience.org/news/minds-business/eve...

https://juliety.com/effects-of-distractions-at-work

https://news.harvard.edu/gazette/story/2019/11/why-open-offi...

I don't mind it being me, as a matter of fact, it's often me, as I am in a more senior position and have a lot of historic context. However, a lot of time has been spent on documenting most things, so often I am just going over the docs with the new onboarder, which is okay, as long as it's done in a structural manner.

> You don't have normal boundaries. Grown-ups at work know that they will interact with other people. You inventing that people should not interact with you, or interact only in your own terms even when it is inconvenient for them.

I don't mind interacting at all, nor do I mind onboarding. I do mind, however, being interrupted all the time, on information, that could easily have been condensed in an onboarding package if the company gave people the space, time and initiative to create such a package.

What I am pointing out is that the OP experienced bad onboarding and thought the solution to that is being in-person in the office. I would argue what they simply had was a badly planned onboarding, with randomly shared responsibility across the team, and an ad-hoc learning plan. If the OP's company uses that lesson and makes a better onboarding process, that'd be great and they might even reconsider the need to be there in person.

> you are complaining about doing your job: working with colleagues and sharing information so that they can progress.

I would love share the information, but I want to do it in a structured manner, and not in chunks and without disruptions.

That's why schools and unis have classes, and classes have predictable and scheduled time frames. It's not just a building with teachers, and random children entering ad hoc and asking whatever question came to their head, then leaving, and coming back 5 min later.

And what's wrong with wanting lots of this information to be self-service? That's the whole idea of knowledge bases, of onboarding docs, of developer handbooks. What does it have to with people being in person or not? I'd argue if the OP's company spent the effort in actually putting all that knowledge in writing, they will have an easier and less disruptive onboarding to the team, with reduced bus factor, and clearly documented steps.