I quite agree. Unfortunately management wants single-threaded code and wants it documented with flowcharts. So right now there's lots (!) of clouds detailing "this calls into another API documented in another flowchart..."
To me, that screams "put your resume out on the street".
I mean, I'm not opposed to documentation. It's important. But if your management thinks that flowcharts are the way to do it, I wonder what millennium they think it is.
Indeed? Flowcharts aren't the only documentation. Swagger describes the API parameters, flowcharts describe the API code flow, and text provides a story, and comments in the code describe particulars.
Flowcharts are just where I've felt that I've significantly underperformed; where management has asked for more of them.
Putting my resume on the street is something I do often. Want to look at it?
If you think flowcharts aren't the way to describe code flow, then I'm curious what method you think is better.
Ah. Flowcharts were all you mentioned, so I assumed (bad move) that they were all you did.
Depending on what exactly you are doing, parts of UML might be better. It lets you describe different aspects with different diagrams, so that, if one kind of diagram is sub-optimal for showing some aspect of what's going on, another kind might be better.
I mean, I'm not opposed to documentation. It's important. But if your management thinks that flowcharts are the way to do it, I wonder what millennium they think it is.