3 ms·

This comment reminds me of Feinman describing how he out-computed an abacus expert just extrapolating from a few facts he had memorized. I think mental working

This comment reminds me of Feinman describing how he out-computed an abacus expert just extrapolating from a few facts he had memorized. I think mental working space is limited and should be optimized on (as in, don't load your mind up with too much low level stuff), sure, but it's the ability to synthesize known tool sets and their capabilities rapidly that helps more. Learning 'another way of thinking about it' is generally the value of doing these first principles style tutorials although I think one can take it too far.

DanielBMarkham 9y ago
Yep. And what happens far too often is developers concentrate on one layer and framework, then spend all their time learning tiny details about the abstraction system they're using instead of the job they're doing. New version comes out, something breaks in a non-obvious way, the industry moves on? They're left with a head full of nothing.
- reificator 9y ago
  That's less about layers of abstraction and more to do with intellectual laziness in general. Abstraction is a tool, and like all others it can be abused. > All problems in computer science can be solved by another level of indirection - except for the problem of too many layers of indirection.
  - DanielBMarkham 9y ago
    I agree it is about intellectual laziness. I was a developer for a decade or two before I finally realized something critical to my career: other developers are actively selling me on things that may or may not be a net benefit to me as the years pass. Developers are a market just like any other, so people make abstraction layers and then become "evangelists" that go out and sell people on stuff. What's to sell? The idea that the framework takes away all the hard work. (I was a big sucker for frameworks with slick UIs back in the day.) We want to believe with a minimum amount of thought, something super cool that will come out that users and other developers will fawn over. Once I started teaching developers, I ran into people who called themselves professionals but were unable to think through simple activities. Yes, these people were lazy, but they were also products of an environment where they were just moving from shiny object to shiny object. They knew a little bit about various abstraction layers here or there, but nothing about how anything worked. Most of the time, once they went off "happy path", they just banged away at the compiler until things looked like they were working. And these were people being paid to program! I completely agree this is because of laziness. I don't think it's the entire picture, however.
    - barrkel 9y ago
      I think it's a different method of working, and I'm not sure either is absolutely superior. They have different strengths in different environments and time horizons. I personally have a hard time working on something when I can't see through the abstractions to how it works, at least to the CPU and network level. Without knowing how something is working, I don't have a mental model of failure modes or performance characteristics, and I don't know how to compose a solution from the bottom up that will scale well and work reliably. Thus when I come into something new, I'm frequently less productive than I've observed other people to be, who just take the abstraction at face value, and start coding in terms of it. I catch up in the medium term and overtake in the long term though, because I can debug implementation issues and don't fall into traps where the abstraction is a poor fit. I consider these two different styles of working as top-down (abstraction first) vs bottom-up (needing to understand the mechanism). The two styles use very different methods for evaluating third-party libraries and frameworks. Top-down tends to evaluate for popularity and social proof above all else. Even if it only covers 5% of the solution and needs workarounds and add-ons for core solution use cases, it gets used because it's popular. Whereas bottom-up tends to evaluate for conceptual and implementation simplicity, possibly at the cost of under-abstracting the solution, and running the risk of NIH causing redundant work. Top-down tends gets something up and running and demoable / sellable faster. If you're ambitious in a big organization, or early in a startup, it's the way to go, because it looks like you're moving really quickly, and for MVP purposes you are. Bottom-up tends to build something that will last and can be maintained in the long term, with a smaller semantic gap between the problem domain and the chosen abstractions for the solution, usually because there's an extra abstraction layer that's missing in the top-down solution. That layer that bottom-up tends to build, and top-down doesn't, is very similar to what Paul Graham talks about in programming bottom up in Lisp: http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html - changing the language to suit the problem. You build a library that lets you compose solution primitives at a higher level with just the right chunking for your problem.
js2 9y ago
It’s worth pointing out, I think, that Feynman concludes by saying that a bit of luck was involved: “Furthermore, the whole idea of an approximate method was beyond him, even though a cubic root often cannot be computed exactly by any method. So I never could teach him how I did cube roots or explain how lucky I was that he happened to choose 1729.03.”

DanielBMarkham 9y ago

Yep. And what happens far too often is developers concentrate on one layer and framework, then spend all their time learning tiny details about the abstraction system they're using instead of the job they're doing. New version comes out, something breaks in a non-obvious way, the industry moves on? They're left with a head full of nothing.

reificator 9y ago
That's less about layers of abstraction and more to do with intellectual laziness in general. Abstraction is a tool, and like all others it can be abused. > All problems in computer science can be solved by another level of indirection - except for the problem of too many layers of indirection.
- DanielBMarkham 9y ago
  I agree it is about intellectual laziness. I was a developer for a decade or two before I finally realized something critical to my career: other developers are actively selling me on things that may or may not be a net benefit to me as the years pass. Developers are a market just like any other, so people make abstraction layers and then become "evangelists" that go out and sell people on stuff. What's to sell? The idea that the framework takes away all the hard work. (I was a big sucker for frameworks with slick UIs back in the day.) We want to believe with a minimum amount of thought, something super cool that will come out that users and other developers will fawn over. Once I started teaching developers, I ran into people who called themselves professionals but were unable to think through simple activities. Yes, these people were lazy, but they were also products of an environment where they were just moving from shiny object to shiny object. They knew a little bit about various abstraction layers here or there, but nothing about how anything worked. Most of the time, once they went off "happy path", they just banged away at the compiler until things looked like they were working. And these were people being paid to program! I completely agree this is because of laziness. I don't think it's the entire picture, however.
  - barrkel 9y ago
    I think it's a different method of working, and I'm not sure either is absolutely superior. They have different strengths in different environments and time horizons. I personally have a hard time working on something when I can't see through the abstractions to how it works, at least to the CPU and network level. Without knowing how something is working, I don't have a mental model of failure modes or performance characteristics, and I don't know how to compose a solution from the bottom up that will scale well and work reliably. Thus when I come into something new, I'm frequently less productive than I've observed other people to be, who just take the abstraction at face value, and start coding in terms of it. I catch up in the medium term and overtake in the long term though, because I can debug implementation issues and don't fall into traps where the abstraction is a poor fit. I consider these two different styles of working as top-down (abstraction first) vs bottom-up (needing to understand the mechanism). The two styles use very different methods for evaluating third-party libraries and frameworks. Top-down tends to evaluate for popularity and social proof above all else. Even if it only covers 5% of the solution and needs workarounds and add-ons for core solution use cases, it gets used because it's popular. Whereas bottom-up tends to evaluate for conceptual and implementation simplicity, possibly at the cost of under-abstracting the solution, and running the risk of NIH causing redundant work. Top-down tends gets something up and running and demoable / sellable faster. If you're ambitious in a big organization, or early in a startup, it's the way to go, because it looks like you're moving really quickly, and for MVP purposes you are. Bottom-up tends to build something that will last and can be maintained in the long term, with a smaller semantic gap between the problem domain and the chosen abstractions for the solution, usually because there's an extra abstraction layer that's missing in the top-down solution. That layer that bottom-up tends to build, and top-down doesn't, is very similar to what Paul Graham talks about in programming bottom up in Lisp: http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html - changing the language to suit the problem. You build a library that lets you compose solution primitives at a higher level with just the right chunking for your problem.

js2 9y ago

It’s worth pointing out, I think, that Feynman concludes by saying that a bit of luck was involved: “Furthermore, the whole idea of an approximate method was beyond him, even though a cubic root often cannot be computed exactly by any method. So I never could teach him how I did cube roots or explain how lucky I was that he happened to choose 1729.03.”