Unfortunately a lot of otherwise capable people that could benefit from some simple structuring of things and their relations have never thought about the world in that way and may take a little while to catch up.
In some cases I have found it to be easier to represent one-to-many relations as a bunch of stacked boxes on the "many" side. But that only works once...
Sequence diagrams and state-charts helps from time to time, but does not really help much when talking to non-professionals.
But I don't really like the very formal UML. Some bubbles, arrows and crow's feet will do fine in most cases. The precision promised by UML is really a lie, as most diagrams are simplifications and can probably not represent the actual complexity in anything that warrants the use of UML...
Anyway, I think it might actually be a good idea to do some simple entity-relationship analysis in schools at some point, if not to just get another tool for sorting out the mess.
The underlying reason that led to OO-languages still exists, namely that a lot of things can be described rather nicely with entity-relation maps. It's just unfortunate that the "relation" part was forgotten, and all energy was spent on wrestling various languages into bizarre "OO" hacks such as C++.
Doing modeling without it is like analysing logic with without boolean algebra or 1st order logic.
And thete is nothing to it - it just focuses your thinking and communication.
Otherwise, all I've ever seen anyone do is take their actual design diagrams and laboriously turn them into UML diagrams of some kind for a document. The recipient then took the UML diagrams from that and made their own new sketches from that, turning them into something they could easily read and understand and that generally looked very similar to the original diagram that was laboriously translated into UML.
My conclusion is that a UML diagram is better than nothing, but not as good as a well-written and well-explained design. I suspect UML diagrams are meant to be part of a well written, well-explained design, but for any given design there seems to be a better way to draw it than UML diagrams.
One of my side projects is an automated nwdiag mapping system with diff's to be able to help sysadmins coming in blind to orgs (happens way more than you'd think, usually a 5 yr old visio file somewhere).
Anyway, in the future I see uml style things as useful for similar automation projects, due to the simple text nature.
Also, I live in a terminal most of the time so personally prefer stuff like nwdiag over say visio or some of the alternatives.
I also used to make repair flowcharts with seqdiag for my t1 and 2s.
I work at a kind of graduated tech start up, so we're doing most things the modern way. I've never even heard anyone mention UML.
Class diagrams are more or less useless, and it's mostly requested by non-professionals that can't read code. Use case diagram are more or less irrelevant too, with just an actor connected to one or two things.
I think that it's mostly administrative (in house) systems that models reality and complex processes that benefits from a modest dose of UML diagrams, not typical applications.
In my experience, people don't like to document, developers even more, and managers probably don't like to read documents, either. However, if people leave your company (something highly probable), how are you expected to train the new people?
If you are working in a startup, that's not major problem: the startup may just die and you can have fun programming in the meantime. However, if there is company that intends to last more than a few years, ways of documenting your system are needed.
IMHO, not using UML, or any other language, to think about our systems or even tell others how they work is a complete mistake. It is not only for telling others (colleagues and future workers) what the system does and why it does it that way, it is also to save effort and realize sooner that it will not work.
So, whatever the case, training in how to explain your system to others is required. Call it UML or whatever. And, since UML is there, it may be worth to use it. It is not just the invention of a couple of mad engineers. You are free to use UML as you like. And do not need to use a huge tool. Text UML is a nice and refreshing way of looking at UML which I strongly recommend. Have a look at http://planttext.com, for instance.
Simplified UML class diagrams (i.e. boxes and arrows) are expedient for explaining specific aspects of a design. Complex class diagrams trying to give an all-encompassing picture of an application: Not so much.
Sequence and activity diagrams can be quite useful for clarifying application state, too.
Are you using RUP? https://en.wikipedia.org/wiki/Rational_Unified_Process
I've been using these in the past [1] MonoDraw and this free [2] diagramming website. Came across [3] Draw today, although I have yet to try it.
[1] https://monodraw.helftone.com/ [2] https://www.websequencediagrams.com [3] https://www.draw.io/
It amazes me the amount of time I see convoluted discussions when a simple diagram would make it so much simpler and explicit.
If they're used as an analysis/design tool and not as a documentation-after-the-code-is-written tool, with tools that generate code from the diagrams, they are really powerful.
I work in Embedded Software and mainly use: Use Case Diagrams, Statecharts, Sequence Diagrams, Component Diagrams, Class Diagrams. The 80/20 rule is true, and I think about 80% of the value comes from 20% of the entirety of UML.
I personally like them, maybe because I like thinking of the big picture no matter the task, plus we had extensive practice on uni.
But the key to benefiting from UML is to first decide what subset of the whole language you need and focus only on that. Very few companies will find a use for the 13 types of UML diagrams.
For Python code, one can use pyreverse to generate UML representation.