As a professional developer, sure, I'd say it's helpful to learn the underlying layer at some point but it doesn't have to be now, tomorrow, or a year from now. There's so much to learn with computers it's impossible to get to everything even in a lifetime.
Some people can be interested in the outcome of programming, they aren't here for craft or solving puzzles, and that's awesome! It means we've made tools easy enough for people to be empowered to create a piece of the internet they want to see, which IMO is more important than what they are creating with or how they are creating.
I've some sympathy with this position - I'm an outcomes oriented kinda person too! I much prefer to just get stuff done rather then argue about monads. Or project directory structure. Or where to put the bins out.
But I'd argue that the tools we build at the apex - the so-called frameworks - do more to slow productivity than to enhance it. How long have I spent debugging an Angular app I didn't need, or a Wepack compilation failure for a simple piece of Sass that could have been CSS?
This I suppose is the stronger version of my position: it's not just that we all ought to know the underlying layer, it's that the things we're using on top are often actively harmful to getting things done.
I think for the situation you are describing you're right, unnecessary middleware can make simple tasks more complicated than it needs to be. Although if a tool is causing more problems than it solves, it's either not working correctly (buggy software) or it's life has probably run it's course (old software).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a professional developer, sure, I'd say it's helpful to learn the underlying layer at some point but it doesn't have to be now, tomorrow, or a year from now. There's so much to learn with computers it's impossible to get to everything even in a lifetime.
Some people can be interested in the outcome of programming, they aren't here for craft or solving puzzles, and that's awesome! It means we've made tools easy enough for people to be empowered to create a piece of the internet they want to see, which IMO is more important than what they are creating with or how they are creating.
I've some sympathy with this position - I'm an outcomes oriented kinda person too! I much prefer to just get stuff done rather then argue about monads. Or project directory structure. Or where to put the
bin
s out.But I'd argue that the tools we build at the apex - the so-called frameworks - do more to slow productivity than to enhance it. How long have I spent debugging an Angular app I didn't need, or a Wepack compilation failure for a simple piece of Sass that could have been CSS?
This I suppose is the stronger version of my position: it's not just that we all ought to know the underlying layer, it's that the things we're using on top are often actively harmful to getting things done.
I think for the situation you are describing you're right, unnecessary middleware can make simple tasks more complicated than it needs to be. Although if a tool is causing more problems than it solves, it's either not working correctly (buggy software) or it's life has probably run it's course (old software).