5 ms·

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 som

by matesz 6y ago

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 https://delong.typepad.com/files/adler-read.pdf

stack_underflow 6y ago
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.
- Raidion 6y ago
  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.
  - stack_underflow 6y ago
    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.
    - colineartheta 6y ago
      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).
      - stack_underflow 6y ago

by matesz 6y ago

stack_underflow 6y ago

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.

Raidion 6y ago
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.
- stack_underflow 6y ago
  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.
  - colineartheta 6y ago
    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).
    - stack_underflow 6y ago