Hacker News Reader

Comment by matesz | Hacker News Reader

The best thing about reading technical books is that it naturally leads one to get aquainted deeper with the topic at hand.

Usually many ideas spawn out of some brilliant work which is published for a while already and its really worthwhile to try to track down those.

Knowing history makes it easier to understand works which in some way depend on the original, even small bits - something called syntopical reading.

While this is obvious to many I’ve always struggled to get myself to read those early works.

Now obvious question is what is the best book to read on the topic of reading books?

I think one of the best is “How to read a book” by Mortimer Adler. It is about all books and cannot recommend it highly enough. It is in public domain already unless I’m mistaken so here is a link [1].

[1] https://delong.typepad.com/files/adler-read.pdf

View on HN

I feel like I'm on one extreme of this spectrum which is: I 'need' to develop a deep understanding of systems from the bottom-up and only then can I feel comfortable building on top of it/abstracting it away/being productive with it.

When I started learning socket programming I didn't feel completely comfortable with using it until I had a complete understanding of the networking stack from the PHY upward. I even needed to write my own simple ARQ implementation to feel like I could fully appreciate and have a "feel" for what two machines are "actually doing" when they're sending packets back and forth.

I had the same obsessive desire to completely understand from the bottom-up how database engines were implemented because I just didn't feel comfortable with just the knowledge that "selects on tables with indexes on the field being queried are 'fast'". I just _had_ to know what was making them fast. Funny thing, when I found out that databases and database indexes were just disk-persisted/in-memory self balancing search trees or hash tables, I thought to myself, "that's it? why didn't anyone just tell me that instead of just repeating "queries are fast/optimized by the db"?"

I don't know if my brain just works differently because it seems most people I've worked with seem to get frustrated/annoyed with these details and not even have any desire to learn a system in-depth like this. They seem to only want to reason about a system at its highest level of abstraction, whereas to me, with the database example, once I learned that B+ trees were one of the primary data structures that backed database systems, I felt like the system as a whole just became that much more transparent and easy to reason about because now I could leverage all of my intuitions+past experiences relating to performance of operations on tree structures, having an intuition of perf implications of using linked data structures, reasoning about issues like paging chunks of data in and out of disk, etc.

You just have an interest in different parts of the stack. Someone could write the same thing, but instead talk about why they needed to understand how the computer hardware was implemented to run the programs and even needed to build a small computer themselves to get a feeling for what the computer was "actually doing".

Alternately, at a systems design level, the constraint may not actually be the implementation of the components, but the organization and production of the system. This could be a simple CRUD app, where the business domain is more important, or the manufacturing of a new toy, where cost retooling and speed of production matters significantly more than trying to make the toy of a slightly higher quality.

There is a LOT of complexity out there in the world, and most people (on hacker news especially) gravitate towards parts of that complexity that interests them. A lot of other people gravitate towards different problems, which is a good thing, because it takes all sorts of specialties to get something nifty off the ground.

That's a really good point. I've also done what you mentioned in your first paragraph but stopped digging deeper once I hit the "now I have to understand physics to actually understand why electricity behaves the way it does in order to flow through transistors/logic gates" barrier. My reasoning at the time was a combination of asking myself how much time I actually had to dive into that as well, plus how much of a potential return I thought I could get from having resolved those questions.

Both this and your above comment might just be the most uninvited and self-absorbed accounts of internal reasoning I've encountered in a neutral space online in a long time. Maybe you can do a deep dive on your presentation and determine the abstract reason why you think colleagues aren't interested in the same things as you (hint: it's not the topics).

Seems like I struck a nerve here... I didn't realize I'm not allowed to use HN to start discussions with other readers about topics they bring up :)

I like to post about these kinds of thoughts on HN because I feel the crowd is the type to offer useful insights I don't find elsewhere on the internet or even IRL. Do I have a tendency to ramble? Sure, look at my post history...

If you have any insights about what I mentioned (a thing I've been curious about for a long time), I'm all ears - but I don't see how being salty is contributing.

I can understand why my comment reads "salty" - I apologize for that. In all honesty, based on what you said, I actually think you and I have much in common (having undergone similar technical exercises for the pure sake of understanding). My issue was/is your delivery (albeit typed and perhaps it is just the medium, again, apologies) - you didn't start a discussion, even when the parent responded you hardly even acknowledged what they said before you simply doubled down on speaking "at" them/us about yourself and your interests in affirmative statements (that in all honesty read like you're "one-upping" everyone for some reason) that leave open very little room for an equitable response. I guess, what I'm trying to say, is that I think human nature is such that people want to feel comfortable with another human before diving into a technical topic with them (even on HN!). That rapport is subtle and relies on so much more than just factual knowledge or a common project; it needs genuine, mutual interest in other people, and if I could make any suggestion (advice I try to take myself) it would be a more polished delivery. Or, as my mom always told me, "it's not enough to be right all the time - you have to be kind, too."

Reply on news.ycombinator.com