Why do programmers need private offices with doors?

I advocate for a culture where onboardings are mostly self service and most documentation is up to date, frequently available, and easy to access. A culture where people are not afraid to ask questions, but they rarely have to, because most of the stuff is at the docs, and they never wonder who to ask, because they've been told who their onboarding "buddy" is. The person being onboarded is also aware that it's probably a good idea to batch their questions into a list, so they can discuss them with their buddy during their scheduled meetings, but is also not afraid to ad-hoc ask questions, because no documentation is perfect. If these ad-hoc questions are too much and too often, it might be that something in the self service is missing, and that is remedied accordingly.

In the culture I advocate, everybody's satisfied, learned well, and mindful of each other's time and flow, and it has nothing to do with being in the office or not. In fact, I have anecdotally noticed that in-person companies are more likely to use existing people's time and attention as crutches for compensating for a the lackings of a comprehensive on-boarding plan, which is what I believe the OP experienced and wrongfully thought to be the solution.

Hard agree!

I do, however, believe there is lots of merit in establishing proper communication channels and protocols. Things written down do tend to stick more as institutional knowledge, and can be referred to later by other newcomers or when you simply don't remember why something was done. Contrast that with: "Oh yeah, Barry told me to do it like that last week while you were sick".

> But this is not what we are talking about. No one here is saying that this should not exist. But is not sufficient.

Also hard agree! Written docu and knowledge bases can never (and probably shouldn't) fully encompass all the institutional knowledge. Talks and clarifications are constantly needed. But let those work in an async manner, or in a focused effort, not random questions flying around. When you are done refining something, and the questions keep pouring in, sit together again to create a shared understanding, update the shared understanding, and 9 times out of 10 you will see the questions subside to a reasonable volume.

> Let me demonstrate to you why. In software development, the whole process is based on the fact that bugs will happen. There are linter, code reviews, version controls that allow reverting, logs built in the code, advanced ticket system to deal with bug raising, ... Coding perfectly in one go is hard, impossible.

Hard agree. I'd go as far as to argue that pre-planning everything in advance is insane as reality hits back pretty hard.

> Because of that, documentation is bound to be more often incorrect than the code.

Also hard agree. Tbh, I don't believe in documentation too much (gets too stale, quickly) unless it's autogenerated (API docs, for example) or set of often tested instructions what to run, or even loosely describing what this repo is all about. Another type of useful documentation out there is "aggregator" documentation, which simply gives you a list of all relevant things to do/check/read to get a good understanding of a problem at hand.

> It does not mean it should not be done, but it means that we should continue to continuously fine-tune our understanding, and it includes asking quick and easy questions.

Agreed 100%. However, if you see the quick and easy questions coming at too high of a volume that it overwhelms the team, then the team's institutional knowldge is being used as a crutch, or somebody is unsure of their understanding, and we should address that, rather than simply accepting it as an unavoidable fact. Maybe the person is too junior and needs dedicated handholding and going through the docs/repos/code together for a longer (scheduled) time? Maybe the docs are wrong? Maybe the consensus of last meeting was not really a consensus? All of these are things to be addressed, and not simply accepted that your colleagues always need to be there to enable your flow.

> In fact, it is not even that their way of working is not the same as yours: you even seem to be asking people to do things that you will refuse to do yourself.

I am asking for being mindful of other peoples' times and not advocate for people being at their disposal because of a bad onboarding experience they had. The OP is, in a way, advocating for returning back to an old way of working that was deeply inefficient to me and my team, just because they like it, without providing a notion whether his team mates liked it (I guess some did, some didn't).

I am simply sharing the viewpoint that while some people really LOVE to ask questions and to immerse themselves in the office space, some don't, because it cab be really disruptive to their own flow and wellbeing.

Hard agree!

> But more importantly, a grown-up would say: the two persons are collaborating, they are not fighting each other. The person who has knowledge is a grown-up, they will want the work to progress correctly and they will want to see their colleague succeed professionally and socially. The person who needs the knowledge is a grown-up, they will not ask over and over again when they see it disturbs the person who has the knowledge (and no one here is against that, obviously).

Hard agree!

> In short: grown-ups understand that communication is messy and that "counting points" is just ridiculous, inefficient

Agreed. However, as engineers, if we see communication within the team being messy, you also need to judge is that okay, or could we improve it, by setting some ground rules or improving some process or maybe having more dedicated sessions for creating a good shared understanding. OP's thread, it felt to me, thought that messiness in communication was solvable only by being on-prem and able to ask quick questions, while I am convinced it can be solved far more elegantly and with less overall effort with a good, focused onboarding experience and even (or especially) in remote settings.