All three companies I have been at make heavy use of architecture diagrams, though their rules and prevalence vary from team to team. In fact I can't imagine a

All three companies I have been at make heavy use of architecture diagrams, though their rules and prevalence vary from team to team. In fact I can't imagine a high functioning software organization taking a project from requirements gathering to production support without having ever made an architecture diagram. However, teams usually do not follow any hard rules like UML. A box with text, a connecting line, and a grouping border can all mean anything, and the subtleties of their actual implementation are still trapped in the lines of code and minds of architects. I would definitely recommend drawing diagrams of systems you create or work with. If there is not one at work, and you're struggling to grasp the big picture, start making one yourself. Start with the pieces you know and put in ambiguous boxes for the pieces you know exist but don't know what they do. I do this even for solo side projects when they have more than one physically-separated component. This will help you catch bad logic and inefficiencies early, and find the best implementations for new features down the road. I have used draw.io (now diagrams.net), LucidChart, Microsoft Visio, and they all get the job done. I'll recommend the first one as it's the most open.