That said I've written plenty of UML documentation and even if someone knows how to create class diagrams most don't know how to do interaction, state or activity diagrams.
Which is why I'm a bit taken aback if someone is bogged down with class ones.
But really why worry about UML class diagrams, there are tools for that (I believe Doxygen does it for you automagically), it does sound strange that your job has a requirement for it since anyone can learn class diagrams in a couple of days and if they are used at work then they won't forget, but since most places won't even use them, then it's ok to look it up when needed.
...Tools? We're talking about being able to draw boxes with names, and draw differently styled arrows between them! I mean if the guy had just mixed up arrow styles, I wouldn't have batted an eye... He didn't know where to start.
Also, as I mentioned, in my professional life, class diagrams have been a principal tool of communication, and usually come well before the first line of code. (In fact I generate a lot of code
from UML at my day job.)
Edit: and as for "being kind of like an EE not remembering the symbol for a resistor" that's just plain wrong, flowcharts are the common ground symbols. There are numerous other diagramming models out there each specific to specific tasks and industries.
Well depends on what you're doing. If you're thinking at the level of algorithms, then yes, flowcharts are the basic tool. However, in enterprise application design, before algorithms comes domain. (As in, the real world problem you're trying to solve.) You need to know
what you are doing before you can think about the how.
I can't imagine doing that without some kind of class diagram.
If flowcharts are tactics, then class diagrams are strategy. And yes, there are other diagram types. If someone can draw up the domain in ER diagrams, I'm okay with that, even if it's another world. But in cases where you're doing something more complex than a blinking LED, you need domain analysis, and if you have more than one person on the project, you need a way to communicate the design in its entirety.
Software design and programming are not quite the same thing.