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 hor

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.