That’s fundamentally a lack of respect for the engineering aspect of software systems and a sort of self-loathing embraced by people in the field.
Many software roles require what I would call Home Depot skill levels. People at Home Depot take semi-finished materials in a kit and fix their toilet, without understanding how it works.
Likewise, some journeyman skilled developer and “code” a sign in page with an API without understanding the engineering process around OAuth.
The problem is many business people don’t understand anything beyond the Home Depot kit... they see stuff on the shelf and don’t understand that at some level that engineering side of the work needs to be done to create something novel. Reinforcing that notion are vendors hawking products.
As someone with Home Depot skills, I 100% agree. I really wish that there was a common distinction. I am not the right person to solve a novel or complex engineering problem. I am the right person to build a product that won't require solving a novel or complex engineering problem. I probably shouldn't be paid like the former, nor should I have to have the qualifications of the former to land a job for the latter.
I think there’s a further subdivision of “hard” which is the fundamental research stuff that pushes the boundaries of CS. Then there’s business problem stuff that’s hard because of scale, surface area and general messiness of the real world. Although the IC salary peaks might not be as high, there is more money overall in the latter, and it’s not as much about raw intellect as it is about moving up and down the abstraction layers, thinking things through and translating technical trade offs to laymen.
I think this an interesting analogy. Taking it further - what's great about the Home Depot level skills is that they are often sufficient for me to be able to do routine basic maintenance. This is in-part because many things have become simpler and designed to be easily/cheaply replaced. I think the same could be said for software. That's generally a good thing and was an intentional movement in the industry
That said, I probably don't want to be building a house from scratch with my level of skills and should hire someone with specialized knowledge. Likewise it's also an important skill to know when you will be in over your head and when you need to hire someone to get a job done correctly
I'm another mostly "Home Depot" coder and can glue all kinds of things together without really having to dig deeper. Maybe I could go deeper if I needed to, but that's not what my job demands or requests of me, and what they need is the Home Depot code that bolts all their existing systems together.
I think those of us in roles like this can actually bang out a lot more LOC than somebody working on lower level problems, because we aren't solving hard problems, we're using basic data structures and tossing them between (usually/hopefully) well documented interfaces. If that's the case, LOC is just about the worst metric you could imagine.
Many software roles require what I would call Home Depot skill levels. People at Home Depot take semi-finished materials in a kit and fix their toilet, without understanding how it works.
Likewise, some journeyman skilled developer and “code” a sign in page with an API without understanding the engineering process around OAuth.
The problem is many business people don’t understand anything beyond the Home Depot kit... they see stuff on the shelf and don’t understand that at some level that engineering side of the work needs to be done to create something novel. Reinforcing that notion are vendors hawking products.