I think it really depends on the project size and the kind of work. If you're more in a waterfall model, where the specs are clear and you just got to do it, I

I think it really depends on the project size and the kind of work. If you're more in a waterfall model, where the specs are clear and you just got to do it, I can understand how being able to work uninterrupted is a nice-to-have. But if you work very closely with the business and often run into things that could be done or understood in different ways, having to wait a day or more to get a clarifying response would not work. And this is know-how that can't be written down easily if at all, since a lot of decisions are purely based on experience and historical knowledge. I used to have this illusionary vision of how everything should be neatly documented, but if you operate on a constantly changing code base, it's really hard to find a good balance. Documentation gets outdated every few weeks and sometimes days, plus most of the time, you don't even know that said documentation has been written. As such, you can't fully trust the documentation and you always have to check out at least part of the code. What seems to work for me, is documentation that gives a broad overview of a topic and then gives certain pointers into the code. That way you capture the essence of functionality that is likely to remain for a longer time and the transition from documentation to code is made easier. And finally, if someone is stuck or doesn't understand something, I find it problematic to have the expectation that nobody may be available to read your message for the next few hours or whole day. What is more efficient, someone spending a couple of minutes to provide assistance or someone googling/search Jira/wiki/Confluence for half a day and not making any progress?