Well, the opposite can be just as big of a problem. I've had all sort of headaches caused when a developer would change a piece of functionality in one module, but b/c he had no grasp of the "big picture" he didn't anticipate how this would change things in other areas of the app - then we have to hope that the broken use case isn't to "edgy" to be caught by our regression tests before it gets into production.

So, in my humble opinion, saying that fostering "forest" vision is the "biggest mistake" is an overstatement; but, I would agree that there's no way for a new developer to grasp the forest unless you let him/her build a tree house or two along the way. It's up to the team leads and managers to put the quality controls in place to allow this to happen in a way that ensures the app's integrity.

I'll sometimes pair two developers together: one's a good forest guy, one's better with the trees.

I'd say that the OP needs to, as you suggest, solve small sections of the puzzle to get started, but he should make sure he tests these changes along the whole app cycle.