[minhmeoke]

I would have to disagree. If you have a larger system, then onboarding, design discussions, and communicating changes will be more efficient if you have a consistent language and up-to-date conceptual understanding of the system compared to having to perform code archaeology and reverse-engineer the previous maintainer's intent each time you want to change something.

https://www.unravelled.dev/how-architecture-diagrams-enable-...

https://news.ycombinator.com/item?id=37222855

[jillesvangurp]

That's what I would call aspirational usage. Ask yourself is your best use as a 200$ and hour senior architect to be writing onboarding documentation?

I've been in plenty of companies with diagrams and universally they were incomplete, not that informative or helpful, typically outdated, and kind of obvious. That's because they are typically rush jobs exactly because the best people that could be doing these diagrams have way more important/urgent/valuable things to do.