If I need to debug someone's code, probably the first thing I ask is "are there test?" If you are lucky there might be some unit tests ... and they might even all pass too! :)
Sometimes it is easier to debug a test then it is to debug the whole thing (due to isolating the code you are interested in). Even if it is easier to debug the running application, having a semi-decent suite of tests is your lifebelt for making sure you are not inadvertently changing behavior directly or indirectly.
Other things I like to do:
- ask if you are the best person to be doing this? Did it land in your inbox/task-list because people thought of your name first? Is there someone else better qualified/with-context who might be better to do anything before you even start thinking about it?
- look at the change history of the code you are debugging - is it a "hot spot" that has had a lot of different hands fiddling around with it in the past (indicative of code that might have been troublesome and/or buggy in the past, with the risk of dirty hacks increasing as the number of changes per LOC increases...), or has it not been touched since check-in #1? If there have been lots of changes in that code go through the changes and look at the associated bug reports to make sure that any existing unit tests cover those scenarios (you may want to add them yourself if not, before you make any changes).
- when reading someone else's code I actually find it better not to try to equip myself with all of the domain knowledge and docs. Often if the original developers are long-gone then the docs will likely be way out of date anyway, and sometimes it is easier to just be laser-focused on the parts you care about rather than try and get a handle on the whole system. I guess it depends on what you are doing though - i.e. simple bug-fixes or doing something more far-reaching).