[freehunter]

The first person you describe has to have almost endless amounts time and/or technical interest available to them. The second person you describe has a job to get done as quickly as possible and move on to the next job.

The whole reason libraries and frameworks were created is so everyone doesn't have to dig down to the bare metal to get a task completed. If my manager asked me to provision a server to run an application on and I sat down and built my own hardware from scratch and then wrote my own OS rather than clicking a single button in VMware, I'd be fired pretty quickly.

[greenshackle2]

You sound defensive. I don't think the parent meant that one type is better than the other.

The fundamental difference is not amount of free time. It's just a question of interest and what you are good that. There are people who spend their endless free time making shiny web apps just like there are people who spend it designing CPUs for fun.

Depending on your line of work digging to the bare metal does help get your job done quickly. I know a number of embedded systems programmers, bare metal is their job. There are people paid to work on the Linux kernel, to program FPGAs for high-frequency trading, and so on.

And learning the low level can help doing your job quickly even if you are not a systems programmer. All abstractions are leaky and inevitably some low-level problem will bubble up into your high-level application and you will have to deal with it. If you understand the low-level it may take half or one tenth of the time to figure out and fix the problem.

[Jach]

There are tradeoffs everywhere. The parent made it sound like libraries and frameworks are always going to make you go faster, of course that's not always the case and I don't think the parent believes that. It's very often worth it to descend a level or two to do your job, some things can be done faster, lower, though it's rarely worth it to descend all the way to the bare metal or deeper (but sometimes necessary). Another but echoes your conclusion, sometimes a bit of knowledge at those layers will indirectly help at the layers above.

When the subject of many layered JS frameworks and dependency graphs with hundreds of mini libraries comes up I'm always reminded of Rasmus's 30 second ajax tutorial: https://web.archive.org/web/20060507105529/http://news.php.n... (And the modern equivalent: http://youmightnotneedjquery.com/) Very often libraries and frameworks are brought in because they "help us go faster [because of x,y,z]" with some x,y,zs like "we don't have to think about that problem" or "the global architecture/structure is taken care of", but the cost of dependencies sometimes outweighs the cost of thinking about the problem and doing it yourself. Libraries and frameworks are tradeoffs, you'll likely use a lot of them if you look at every layer you can actually influence, but they're not necessarily net boons.

[greenshackle2]

Yeah, I can agree with that. You'll get the most value out of understanding the 1 or 2 layers below. Digging all the way to bare metal is usually not necessary or practical, though it may help once in a long while.

For example, ORMs. If you try to use an ORM without knowing SQL you will have a bad time as soon as you hit performance issues or you have to do something that doesn't fit quite nicely into the ORM model. I have yet to see a project that uses an ORM that doesn't use SQL in places.

ORMs are not necessarily net positive. They make some things simpler at the cost of an extra layer of indirection.

Going a level deeper, knowing how query planners work at a high level will help writing performant SQL queries.

Going as far as understanding how your RDMS is implemented should not typically be necessary. It would help for finding bugs in the RDMS, but that should be very rare.