If your documentation falls out of sync with the production code you're introducing an unnecessary nightmare for whoever may need to update or maintain the code in the future (which may end up being YOU)
I do diagram my code, but I agree it's pointless to go back and keep the chart in sync with the code once you've written it. The better way is to enshrine the intent of the diagram in automated tests.
I personally follow the method in Reliable Software to plan out my code. It keeps your code neat and clean from the very beginning.
https://archive.org/details/myers-reliable-software-through-composite-design/page/n1/mode/1up
Discussion
Normal documentation (think ReadTheDocs) are totally fine and I see them as one of the highest priorities next to integration and unit tests.
But flowcharts...?
I'm old enough that when I was taught, flowcharts and pseudocode were considered equally sufficient documentation of what the code was supposed to be doing, and simple enough to be easily understood.
But I'm literally a dinosaur in this field (pre-Y2K) so what do I know
I think good tests are the best documentation for developers, along with high level written material for design principles and how the code is organized, generally.
Then there's usage documentation, which I agree needs to be kept up to date as the functionality of the software changes over time.