[fullshark]

A colleague did this at a job of mine, I honestly found it obnoxious and presumptuous, this idea that it’s on me to consciously change my behavior to work with them instead of on them to deal with the tiny inconveniences and pet peeves that come from collaboration with someone. Maybe it helped and coworkers aren’t your friends so who cares as long as it does but beware if you do this that I don’t think everyone will appreciate it.

[opsgal]

OP here - I actually agree with this sentiment to some extent . There's a thin line between "here's a shortcut to all the things you might learn about me over time anyway" and "I think my preferences are more important than yours."

Ultimately the exercise was helpful for me because of what I learned about myself and not because of what others could learn about me.

[unabst]

It's this.

The developer mindset almost enjoys documentation because you can absorb it fast, in detail, and get on with the problem in the window next to it.

In the real world (TM), problem solving is often a matter of responsibility and a delegation issue and resolved socially. And often for non-developers, the software they are given is suppose to be the solution to all their other problems. So when there's a problem with the software or they can't understand it, a standard reaction is "which number do I call", "train me", or "can you fix this".

For client facing shops, the developer needs to document for customer service. Customer service needs to handle client/user communication. And customer service benefits most from detailed documentation, to allow them to answer user questions without asking the developer.

If this is a mixed collaboration environment, then communication needs management. There are people that want open channels. There are people that don't. And there are people that are offended when their preferences are not met or violated. Management is a requirement.