Whenever I try to understand a program, I do draw structures of it. But it is NEVER the structure of the source code as is, but some parts the main flow with the unimportant bits left out (what is unimportant depends on the goal of the task at hand), mapped in some way that aligns with the goal of the investigation. It also has to include the runtime components, eg. objects, not classes.

Watching Eric Evans talk about DDD along the example of maps was a real eye opener for me. This: https://www.infoq.com/presentations/model-to-work-evans

I tried to use tools like Enterprise Architect in the past but failed to produce anything useful with them (that includes architecture diagrams - charts based on standards never seem to be fit for what I actually wanted to communicate).

The closest I ever got to usefulness was with database structures, we did manage to generate the actual production schema from ERwin for a SQL database at one place I worked, but of course, not the stored procedures.

>Whenever I try to understand a program, I do draw structures of it. But it is NEVER the structure of the source code as is, but some parts the main flow with the unimportant bits left out

While some tools might be more or less accommodating, there's nothing about visual representation per se that can't do that (including filtering the non-important parts, producing something akin to UML's interaction diagrams, etc).