If you use class diagrams to show the "truth" you are in painland in my experience.

However I sometimes find them useful to extract key parts of the system and showing their interaction. Cutting away many attributes, many helper classes, many other things.

That can lead to pictures which are quick to grasp and then allow further digging based on code.

Maybe before you actually start writing code its nice to create some domain diagrams which you can convert to class diagrams. Saves a ton of time. And you have good discussions about the general high level workings of an architecture. Can be done on a whiteboard. Make some pics and start coding.

Assuming that you're using a modern IDE: it is an order of magnitude quicker to model the domain (classes + attributes) in code and project them as diagrams, say with graphvis.

High level boxes are great for thinking about systems but the key there is abstraction - minimal viable level of detail..

Dont you want to discuss and talk about a design before you even touch a keyboard? In my projects we always discus high level overviews with pen and whiteboards. Nobody should even dare to touch a keyboard.

Absolutely, I pretty much always start with design sessions on a whiteboard (or if remote a call using draw.io).

That discussion is almost never going down the the level of an individual class and NEVER adheres to the UML standard.

Very occasionally I've had discussions about class structure by drawing class name + methods on a whiteboard but having the same discussion using Visual Studio's UML projection was just as effective.

If you're creating diagrams with graphvis, you're just coding on another language. The benefits of diagrams appear when you draw them by hand (or graphically by mouse).

I generate them: initially with my own generator (which is copyright an employer from > 15 years ago), on a later project I found that Doxygen can do do that for you out of the box :-)

For interactive discussion I just use Visual Studio's projection, for databases I use the SQL Server Management Tool ERD projector or pgAdmin if I'm using Postgres.

The point is that you're generating diagrams from code that's already been written, you're not modelling, do you? ;-)

Those are a different kind of diagram than the one you create from scratch to decide what goes in the program.

this phrase caught my eye, "minimally viable level of detail", to which I immediately thought "minimal detail for a coherent thought". That's a cool concept actually I might hold on to and develop.

I think class diagrams are a good way to visually display classes and hierarchy. If I have a package or module that has 10 classes and I want to show inheritance, properties, and methods I think it’s easier to show the class diagram then hand someone 10+ source files.

Also, class diagrams are more useful when you can’t give out source.

That being said, I think you can autogenerate class diagrams from code so it’s not like you should spend a lot of time making them.