[sushshshsh]

It sounds like you have the free time to read long form writing of potentially good/bad value, however I do not and almost all of my engagement and value seeking from this site comes from the comments section.

I typically read the shortest and most down voted comments as those are clear pointers to things that I need to learn/research further, such as "do I gain anything from a piece of writing longer than a tweet?"

[titzer]

The length of this exchange is probably more than the reading time of the OP. So if you haven't already, I would suggest go ahead and reading the whole thing.

I feel like the TLDR'ing of someone else's writing is a negative reinforcement loop that needs to be challenged because it leads us all into doing the same.

Personally I read comments sections to find things that are not in the OP and point out weak points or blind spots--you know, actual discussion.

[sushshshsh]

Why would I read the full source code of the HashMap implementation in OpenJDK when I could read the API in 5 minutes and obtain 97% of the information I need to use it?

The answer of course, is if someone can provide me a two sentence reason that explains very clearly why that extra 3% of value is so crucial.

[tetrahedr0n]

Really interesting point of view. I have some opinions about your logic and I in no way am trying to attack you. I disagree... the irony is not lost on me, either.

Comparing:

- Reading the source code of HashMap vs reading the API.

to

- Reading HN comments vs source articles.

...is not a fair comparison, IMO. Well what is, then? Ok, glad you asked!

Reading HN comments vs source articles is more like:

- Reading the book vs reading the reviews on Amazon about the book.

Comments on an article are not the API docs to the article. Going with your analogy, the API docs of an article would be something like the spec for how a concept fits into a perspective of a topic (...this sounds so confusing...but, just work with me for a minute, please :D). Unlike something like HashMap, articles are almost always going to be less objective and more subjective. When something is subjective, you could think of it like everyone designs their own API docs; the protocol with which you interact with a concept can be designed by yourself.

The problem with not designing your own protocols (perspectives) for interacting with a concept is that you could be missing an arbitrary 3% of information or the information that your gleaned could be of a completely different taxonomy (or unforeseen perspective dependancies, maybe deps that you don't agree with) than what you would have designed if you had read the article.

This matters because when your perspective is guided by the perspectives of others, you miss out on a lot of opportunities to make connections across topics throughout time. Maybe the cryptographic inventions the author describe connect with another detail in an article about DIY satellite programming or some voting machine vulnerability that inspires you to do something bold (whatever, who knows, that's the point); changing the course of your life.

As a species, I think (super opinionated part) we will advance further if as many of us as possible are actively 'reading the books' and 'forming the opinions'. I don't think the amount of value someone can bring to the world is strictly correlated with their IQ. So everyone can bring value to a discussion or a body of work or whatever, if they think critically about it and develop their own opinions based on their own unique perspectives.

[titzer]

Why would you read a tweet about HashMaps being awesome instead of reading the JavaDoc?

[andrewjl]

There's always a risk somewhere in that 3% there is a 1% that can drastically alter your understanding of the 97%.

You can mitigate that risk by reading a summary from a trusted source, however you can never fully eliminate it. Everything is a trade-off.