The quote I was responding to contextualized it to being able to write the few lines necessary to solve the problem. From this perspective, the fundamental und

The quote I was responding to contextualized it to being able to write the few lines necessary to solve the problem. From this perspective, the fundamental understanding for a crud application is quiet challenging, as you'd need to understand * block storage * the way the database handles the data (storage, access, permissions etc) * The way your application interfaces with the database, likely over the wire adding * The entire tcp/IP stack * The VM/runtime you're using to create your application, along with every used library * also everything these libraries use, adding the whole OS to the stack. * If it's a web application, you'll also have to add the browser along with it's JS ecosystem You can keep going, having a fundamental understanding of the problem to a degree that you'd be able to easily break it down into working code in an editor implies you're able to directly understand all error scenarios which every abstraction layer added, this I find impossible. The only project I'm aware of even attempting something like that is SQLites proprietary testing suite, and they're at what, 900+ times testcode vs application code right now? If you instead think about the tech stack of the 80, it had a lot less to keep in mind, as the scope ended at a pretty rudimentary layer. The terminal being the main UI and likely nothing between your code and any persistence you might utilize. But I wasn't a programmer in the 80th, I've formed this opinion by reading about the tools that programmers used at that time. Maybe there was a lot more layers to software development back then too? I cannot say one way or another with any confidence, as I haven't lived through that time period as a working adult.