I start with the design documentation. In particular, the specification - that tells the intent of the thing being looked at.
If possible, I then look at design notes and documentation to get a general flavour of how it has been done, the thought process, the style and nature of the people concerned.
If possible I then talk to the people who worked on it - what does it do? How? Why? Where are the bodies buried?
There's a tendency amongst developers to leap into code: "Let me show you this code". This is fine for them but tends to hijack my needs - which is to understand the high level which gives context to the low level stuff.
It uses vast amounts of brain power to look at little bits of code, out of complete context, and understand anything meaningful. So if possible, getting the developers to talk about the PRINCIPLE, structure, units, modules, whatever all leads to an appreciation of the task.
Only then is it worth trying to get into the code.
In the big scheme of things, looking at the code is like looking at a page full of 0's and 1's. There is meaning but it takes a long time to figure it out. Getting a flavour of where to look and which parts are meaningful helps narrow the search space.
All that said - when there is no doco, no people, and only code - then there is nothing for it but to look at the code.
In that case, I normally don't try and understand it by a slow deep reading, I do a quick pass, skim reading over everything. Sometimes this is just open files and sit with pressing the page-down key. You can get an amazing appreciation of a big picture just by doing this. (And in some cases I even string-dump executable files and trawl those, looking for signatures and patterns. This has been amazingly fruitful over the last 20-odd years.)