> "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job.
It's not your job, any more than a firefighter's job is to be a hose operator, or a nurse's job is to be a syringe operator.
Your job is to produce software that meets the requirements of the business, as a member of a larger engineering organization which needs to be able to function well enough to deliver that software.
Why are frameworks popular? Because they provide a standardized way for multiple engineers, and multiple engineering teams, to collaborate effectively on the same product -- and they make it easy to hire people who already know the frameworks.
If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks.
That's not good for supporting software when the author leaves, and it raises the barrier enormously for onboarding new people. Above a certain scale it's just not workable.
You can be cynical about this and say that it reduces engineers to interchangeable cogs in a machine. Or, you can understand why things are the way they are, understand how to succeed in this reality, and build a fulfilling career path for yourself by providing value that a mere cog cannot. I've worked with a lot of successful, happy engineers who are not cogs, and what separates them from the others is not coding skill -- it's that they all understand this reality.
It's not your job, any more than a firefighter's job is to be a hose operator, or a nurse's job is to be a syringe operator.
Your job is to produce software that meets the requirements of the business, as a member of a larger engineering organization which needs to be able to function well enough to deliver that software.
Why are frameworks popular? Because they provide a standardized way for multiple engineers, and multiple engineering teams, to collaborate effectively on the same product -- and they make it easy to hire people who already know the frameworks.
If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks.
That's not good for supporting software when the author leaves, and it raises the barrier enormously for onboarding new people. Above a certain scale it's just not workable.
You can be cynical about this and say that it reduces engineers to interchangeable cogs in a machine. Or, you can understand why things are the way they are, understand how to succeed in this reality, and build a fulfilling career path for yourself by providing value that a mere cog cannot. I've worked with a lot of successful, happy engineers who are not cogs, and what separates them from the others is not coding skill -- it's that they all understand this reality.