> Read the code. Believe the code. Not what you think it’s doing, not what the comments imply, not even what variable/function/class names imply. What is the code actually doing?

100% agree, but in my experience there's one more step after this. What should the code be doing? If you're lucky, you have tests or human-readable documentation that explains business rules, but in legacy applications, odds are the only way to know is find an enduser that possesses the knowledge. These are the worst time sinks.

One way to be sure what the code is doing is writing unit tests.

Just dumb black boxing is fine: `assert f(0) == 0`. When it returns "Pancake", change to `assert f(0) == "Pancake"`

...repeat until you understand :)

I don't think many can read code efficiently, so people who can do that are special. People who can't have to rely on documentation or slowly trudging through.

There is a mix. Some things you can learn from the code other things you need documentation.

Often it's the domain knowledge that is hard to glean from the code. Especially when bug fixing. For example:

   The domain expert told me this output was wrong but the code appears to be doing exactly what it claims to. 

Trying to get a domain expert to set down and explain why the output is wrong is a skill that took me way to long to develop. Now sitting down with a pen and paper running through the logic with an expert is one of my most treasured information gathering techniques.

You are right. I think that part comes with experience.

I’ve been coding my whole life (since 9 yo, am 35 now) so a lot of this stuff is very deeply ingrained.