It is a common fallacy in software development: you hear it from the clients, you hear it from the managers and marketing, and you hear it from the engineers: give me everything and I pick what I need.
A team lead throws the project specification (all the 2000 pages) over the fence to the engineer: read it and you will know what is required from your component. Or the himself engineer says he has to have a general project overview before he can start writing any code.
The code gets written so that one needs to read every line of it to understand what it is doing.
The system has a bunch of global objects, so that each class knows "everything" about the system, which looks like a smart idea, except it is not.
The client insists on the "comprehensive documentation", expecting that in such way any possible question about a complex system can be answered.
Or the client insists that the system should never break, and thus provide the level of reliability he really needs.
The books tell you about the generic singleton pattern that would work in every instance.
The project manager requires the full test coverage... Well, the test coverage actually should be full...
The logic of it seems to be impervious: if everything is there, we simply pick a part of it that we need. The problem with it is that there may not be such thing as "everthing", as in the case of the singleton pattern: it does not make sense in general, but its partial implementations are straightforward. Despite sounding trivial: simply everything, it is extremely hard to define what it is. On the other hand, it may require more effort to define a specific thing, but at least that effort is finite.
Even when "everything" seems to make sense, as for example "coprehensive documentation", it may be intractable and eventually meaningless: say, if one needs to write a comment for every line of code, then why not write code itself so that it is more readable?
Such an enlightenment bias is a flavour of the software version of Laplace's demon, but the problem with expressing things in the language (and that's what software engineering is all about) is scales differently from material objects: language is not constrained by physical forces, which makes its leverage and complexity huge and its expressive capabilities open, meaning that beyond simplest cases "everything" is intractable.
Because the enlightenment bias is a misjudgement of scale, it usually accompanies the other common biases in software engineering: implementation, speculation, tangibility, activity bias, etc. By its nature, it is an expensive thing.
At any given time, make sure that the person knows just enough to proceed with his work. It does not mean deliberately keeping him in the dark: he will do his work quickly and therefore will have more time to explore a bigger picture, reinforced by the hands-on understanding gained by accomplishing the task at hand.