I've always been pretty good at reading other people's code. As a developer/consultant I switch codebases often, and I agree with the other poster about reading

I've always been pretty good at reading other people's code. As a developer/consultant I switch codebases often, and I agree with the other poster about reading code making you good at reading code. My approach is somewhat different than others mentioned here. I do take the top-down approach, but in a limited depth first mode. I will usually start with the code's entry point and drill into each section, one at a time. However, I rarely drill down to the bottom of each section on the first run through. I guess I have an abstraction filter that intuitively stops me when I feel that I'm passing from "what's going on" to the "how it's being done" level. At certain points during getting to know the code, I will restart from the entry point, drilling deeper into subsections that I now feel are becoming more relevant to my understanding. After a while I switch from the linear scanning into a mode more like random access, where I pick up classes by name or package depending on what I'm trying to understand better, and working my way up the call stack until I reach parts of code that I've already understood. All of this is done statically, ie. by walking through the code in an editor. I rarely step through the code in a debugger. This is mostly because two reasons: I have faith that I can hold a large call stack in my head and I believe I can jump around in the call stack in an editor faster than I could with a debugger. My faith in my brains is possibly misplaced, and has at times failed me. My aversion towards debuggers comes pretty much from the early nineties where building/running was often very slow and one had to get a feel for the code before a debugger became really useful. I'm sure there isn't only one way to do it, this is just how I do it. I hope it helps you in your endeavors!