Tips for understanding someone else's VBA macros

I am a new employee taking over for someone who is already gone. I can program my own macros in VBA, but I'm not the best at understanding someone else's code and I'm not sure what approach to take.Especially since this code violates many programming best practices (contains lots of GOTOs, is inefficient, not well-organized). I don't even know what the code is doing as there's no documentation. My job is going to be to make this code better, maybe even rewrite it. But I can't rewrite it unless I understand what it's doing. The person who uses the spreadsheet and wants me to look it over says it takes 4 hours to run, so it's not really possible to use the debugger to step through.

So, should I make flow charts? Notes in the code? Is there a tool for annotating code to better understand it?

Any tips are appreciated. It looks like this is going to be my job for some time to come, and I will be looking over many spreadsheets like this and trying to make them maintainable and well-documented.

Maybe you can run it then escape out of the macro a few times and check to see where it spends most of it's time (like 90% of the time you stop it hopefully).
Then try to make that faster (maybe you can take the data into an array as opposed to working on a sheet or something like that, or comment it out entirely or just force it to output a given known valid result) then it might become plausible to spend the time stepping through it.

Of course sometimes its easier to just collect the available inputs and the desired outputs and draw up some sort of process as to how it should have been written in the first place, and just code that. Retaining parts of other people's badly written code can be an ongoing pain every time you have to make an adjustment.

Maybe you would need to spend the time convincing the user that they don't need exactly the same output as long as it serves their basic need, and that maybe you can provide something in some sense better then get a bit of flexibility for how it is created. (you can probably offer them a massive improvement in speed at the very least!)

I'd put in a bunch of stops and try to make a flow of each segment - you can time the interval between stops to find where it's gagging. How many pages does the code fill?

Why not ask the person who uses the code what it does for them?

If the existing code is poorly written (typically evidenced by lots of unnecessary Select and Activate statements), as your reference to 'lots of GOTOs' suggests, you'd do better to find out what its supposed to do, then write an efficient version from scratch. Depending on what the code is doing, 4 hours may or may not be reasonable; I've written efficient code that took that long to run because of the nature of the task (interrogating & analysing 12 million records in 150 text files) and the hardware & software (Excel 2000) in use.

Thanks, all of you. The guy who wrote the code is long gone. The situation is so bad that people don't even know what the code is supposed to do or how it gets to the end result. Just that it outputs a report by compiling from many, many other reports.
There are 9 modules called "module 1", "module 2"... and no rhyme or reason to the modules at all. It's bad. Even if I'm going to rewrite it, I still have to understand what it does because like I said the person who runs it only knows that it puts out a report in a certain format.
This is going to be so fun. /s

Thanks again. Marking solved.

You're welcome and thanks for the rep!