I'm writing this with a background of having studied and done a PhD. in software architecture in the early 2000s.

Simply put, good software documentation matters but has the annoying habit of getting out of sync with your software the second you lift your fingers from the keyboard. So, moderate the amount of time you spend on writing especially up-front documentation, like design documents, because they'll have a short shelf life and an even smaller audience. Worst case it's just you. And that's actually fine.

Use them to structure your thoughts. Shoot some versions back and forth with your colleagues to build consensus. And then archive them.

Back when I was doing my PhD. it was peak UML hype. I was interviewing people with important sounding job titles (e.g. Lead Architect) and they'd be in a private office with a prominently displayed Rational Rose box on the shelves. They'd be spending lots of time making diagrams. This job does not really exist any more.

A few years later I decided to practice instead of preach and became a software developer. Now it's a few decades later and I don't do a lot of diagrams. But I do quick Markdown documents or inline documentation. The closer to the source code, the better. I'm actually pretty good about this stuff. And it's stupidly easy to generate this stuff as well these days. Which you should do. Because it really helps others and the future you (come back in four months and you'll find that your short term memory has blanked out everything you used to know about the code).

Why no diagrams? Very simple, they are either too simplistic/trivial or way too convoluted (won't fit on a single screen/slide/document page). Anything in between is quite pointless and tedious to produce. It won't communicate anything of real value that cannot be expressed in a few quick lines of text. Which is much easier to produce. The diagram is what you whip out if you need to put some lipstick on the pig that is your design for marketing purposes. "We have stuff! Look pretty diagram! next slide...".

The other reason is that as soon as you sit down to implement the design, you'll typically refine it on the fly by deviating from it. So, it rapidly goes out of date and updating it is just not a thing that ever happens.

Don't take my word for it. There are millions of projects on Github of just about all sizes. Including quite a few that implement UML editors and IDEs even. Try finding their design documents. You will come up very very short. The larger the project, the less likely it is to have up to date design documentation. You'll find plenty of other documentation and maybe even a wiki of some sorts. But design documentation is not something that is more than an afterthought in the overwhelmingly vast majority of open source and commercial projects (judging from the ones I've been on).