> It is an undeniable fact that today we have a far far greater amount of Scientific and Technological Knowledge

I don't dispute it. What I dispute is the implication I believe your proposing, which is "there is more knowledge, and therefore we need to read broadly and not focus as much on deep understanding". If that is not what you mean, please correct me since I don't see what other implication you mean.

> The utility of some knowledge may not be apparent at its inception but may turn out to be of utmost importance when other fields have also developed so everything can come together into a greater whole.

I don't disagree. But to apply this knowledge later you need to have remembered about it, and writing notes (which is where this discussion started) absolutely helps with this. I'm arguing for writing down the concepts that you found important or interesting at the time, not a synopsis of each subchapter.

> The justification has to do with getting exposed to a greater amount of concepts/ideas and not necessarily understanding/assimilating everything. Here reading widely does make a difference.

But reading widely only makes a difference to the degree that you do assimilate the content and that it changes you.

> Many a time in scientific research one does not even know the utility of something until sometime in the future when things align correctly.

Except we are not talking about doing scientific research (where I agree getting more knowledge is the whole point). We're talking about reading other people's work to get something out of it. And, especially, in this context there is a trade-off between "just in case" knowledge and "just in time" knowledge.

> which is "there is more knowledge, and therefore we need to read broadly and not focus as much on deep understanding". If that is not what you mean, please correct me since I don't see what other implication you mean.

I did not say "not focus as much on deep understanding". I am only talking about exposure to all sorts of concepts/ideas. When the time for application of knowledge comes, depth will be achieved as a matter of course since it becomes a prerequisite. Reading broadly and widely for knowledge (so to say to get a map of the terrain) is different from reading deeply for a specific objective/need and has to be cultivated consciously.

> But to apply this knowledge later you need to have remembered about it, and writing notes (which is where this discussion started) absolutely helps with this. I'm arguing for writing down the concepts that you found important or interesting at the time, not a synopsis of each subchapter.

I think maybe you are confusing my comments with somebody else's and meant this as a reply to somebody else? I have not mentioned note-taking in any of my comments in this thread.

However, In past HN threads to do with note-taking, i do argue for the benefits of this discipline but in the context of this thread i am only arguing for "Reading broadly and widely" (with/without note-taking).

> But reading widely only makes a difference to the degree that you do assimilate the content and that it changes you.

No, mere exposure and fuzzy understanding is many a times good enough. Assimilation can be superficial or in-depth as needs dictate. What Reading widely/broadly enables is to see interconnections/interplay between various subjects the very existence of which you might have been unaware of earlier. This is particularly true in today's times where there is so much knowledge that it is impossible to go deep into everything.

> Except we are not talking about doing scientific research (where I agree getting more knowledge is the whole point). We're talking about reading other people's work to get something out of it. And, especially, in this context there is a trade-off between "just in case" knowledge and "just in time" knowledge.

I was using the example of "Scientific Research" since it is the classic textbook exemplar of knowledge before utility. But the same idea is also applicable to reading various subjects. It is also the case that "just in case" knowledge will generally always trump "just in time" knowledge. As an example, you can write software without knowing anything about predicate logic/formal methods. There is no "just in time" to acquire this knowledge unless you happen to work on projects where they are needed (a very small percentage). But if you were to study this "just in case" and even if you don't use it rigorously the very act of knowing it will allow you think about program construction in a whole new light which will give you superior insight and increase your effectiveness/productivity immeasurably.

> I did not say "not focus as much on deep understanding". I am only talking about exposure to all sorts of concepts/ideas.

This discussion started because the person you replied to was saying "[I was] dissapointed with myself for not taking more notes ... This quote made me feel better about simply reading, getting whatever I get out of it".

You replied "This is the way to approach it, particularly in these times when knowledge is so vast and there is so much to read."

This response, to me, appears to be based on the assumption that because there is a vast amount of knowledge available, one must read more of it and keep up with it simply because there is more of it.

> I think maybe you are confusing my comments with somebody else's and meant this as a reply to somebody else? I have not mentioned note-taking in any of my comments in this thread.

See my comment above, this started with the person your replied to talking about giving up on note taking while reading.

> What Reading widely/broadly enables is to see interconnections/interplay between various subjects the very existence of which you might have been unaware of earlier.

I would counter that one does not see the existence of such connections with only superficial understandings. For example, most undergraduate students struggle, even after many courses, to connect the expected solution to a problem set up for them; to say nothing of being able to draw connections between subjects.

Yes there is great value in being able to go between many domains and to tie them together, but it is not immediately obvious why this would be more valuable than digging deeply in a smaller number

> This is particularly true in today's times where there is so much knowledge that it is impossible to go deep into everything.

See my point from above about the lack of imperative for reading more simply because there is more to read.

> if you were to study this "just in case" and even if you don't use it rigorously the very act of knowing it will allow you think about program construction in a whole new light which will give you superior insight and increase your effectiveness/productivity immeasurably.

I agree that you can't study something "just in time" if you don't know that it exists. The issue is that a great many things can (or claim to) "give you superior insight and increase your effectiveness/productivity immeasurably". You don't have time to learn about all of them. And when choosing to pick what to look at next, I argue that searching for the thing related to your current problem is more valuable knowledge than a that which you get "just in case".

> This discussion started because the person you replied to was saying "[I was] dissappointed with myself for not taking more notes ... This quote made me feel better about simply reading, getting whatever I get out of it". You replied "This is the way to approach it, particularly in these times when knowledge is so vast and there is so much to read.

No, you seem to have conveniently ignored the particular phrase of the parent's comment to which i was commenting, to wit; "simply reading, getting whatever I get out of it, and trusting that I’ve gained some perspective," It is right there at the beginning of my comment and i am expanding only on this sentiment and nothing else. Hence i am not sure where you are getting your other assumptions from. If i had wanted to expand on note-taking i would have explicitly called out the parent's relevant phrases which i did not.

> I would counter that one does not see the existence of such connections with only superficial understandings.

Hard Disagree, you can definitely see some connections with even "superficial" understanding however fuzzy/incomplete they might be. For example, i can tell a programmer to think of the types of his program variables as a set and the variable itself ranging over the collection of values in this set. Next i can tell him to think of his logical conditions using these variables as logical predicates establishing a mathematical relation between various values amongst the above sets. With just this "superficial" knowledge of Sets, Cartesian Product, Relations and Predicates he can now see a connection between Mathematics and his Program enabling him to come up with better and more comprehensive Pre/Post conditions and write "correct" code.

> Yes there is great value in being able to go between many domains and to tie them together, but it is not immediately obvious why this would be more valuable than digging deeply in a smaller number

This should be obvious by now; you are increasing the size of your "known unknowns" and hopefully decreasing the size of "unknown unknowns".

> You don't have time to learn about all of them. And when choosing to pick what to look at next, I argue that searching for the thing related to your current problem is more valuable knowledge than a that which you get "just in case"

Of course Time/Energy are limited and universal constraints on everything a Human can do; that is not an argument. If you are working towards something specific, your study should be targeted but not necessarily limited to it. This is where "Reading broad/wide" is needed. As an example, you have loads of Web programmers today who limit themselves to only using higher level frameworks/libraries to write distributed apps but have no clue (not even "superficial") of the underlying TCP/IP stack. Having some idea of the application layer HTTP protocol and its interactions with the underlying TCP/IP stack is a must for any distributed app developer but because things have been abstracted and encapsulated so nicely many don't even bother getting a "superficial" knowledge of these fundamental technologies thus severely limiting their effectiveness troubleshooting when things go wrong.