In my experience, the broad concepts of UML are applicable and used in real-world engineering/design. By "broad concepts" I mean something like "draw boxes for classes/objects with arrows pointing to related other objects".

Thinking about systems as state machines, sequences, entity relationships, etc is useful. But the rigid details of specific lines styles, arrow types, etc are very rarely used.

Sometimes it seem like "nothing" is used today. People just start writing code. This actually isn't a bad way to go 70% of the time. But if you find yourself struggling it might be time to step back and think it out with some informal UML sketches. Nobody uses "formal" UML anymore.

The main risk of UML is it can lead to overly complex designs - it is so easy to add another box and arrow, to make it match a GOF pattern, etc.

As for what we use here in practice today - pairing and talking out ideas sometimes with informal UML sketch, and test driven development.

Design a notation based on existing norms to whatever specificity you deem adequate).

I like process boxes with four sides.

Left side takes input, the right spits output.

Top side takes constraints, rules, or links to specs.

Bottom accepts triggering mechanism, temporal/sequential constraints, polling, and other controls.

Complex Processes get decomposed down to autonomous objects that can be programmed as desired.

Many of the stripped down existing iconic notations can be similarly instrumented to be useful. Be your own guru.

You're fine. Draw some useful diagrams. Sometimes, generate useful diagrams from parts of code you're having issues understanding (Doxygen, with a little help, can do it). Do not try to create a diagram and generate code from it, and definitely don't ever attempt round-tripping your code and diagrams.

Use the syntax, don't get caught up in the tooling.