> I think you could turn the responsibility the other way around quite as easily, and I think you're mistaken grown complexity, one that is inherent in a company's system (accidental or not), when you outline what you mean as "framework" here.

No I'm not. I'm not reading the rest of your reply because you completely misunderstood me here and then proceeded to give me an insulting definition of what a framework means while completely ignoring the broader point I was trying to make.

In fact, I did the following to add clarity:

1. I put the word "framework" in quotes to make it clear that I was using the term colloquially

2. I elaborated that I was talking about custom supporting code and other tooling that was developed by the company in order to solve domain-specific problems.

I have built frameworks. I continue to build frameworks for my employer on a Platform team. We work with 3rd party frameworks and we need to build on our own. This is just normal encapsulation, building higher level APIs on top of lower level ones.

So when I say "the company's framework" I'm referring to the stuff that was buit in house in order order to develop highly domain specific functionality with a higher level API than what the 3rd party frameworks are providing out of the box.

A framework's super-power is that it applies the Holly Principle: don't call us, we'll call you. That's what distinguishes a framework from a library. Libraries sit there passively waiting for you to consume them. But in our industry, like the word "hacker" and "troll"... people start using the term colloquially. And in this case we're talking about the specific APIs that the company has developed which you need to ramp up on even if you are highly experienced in the specific 3rd party frameworks that they use.

And even if we take the word framework absolutely literally as you did in your comment, companies still build "literal frameworks" internally in order to try and simplify. But you gotta ramp up on those.

At my existing employer, we have even taken 3rd party frameworks and libraries, and forked them and developed our existing custom tooling with them because our domain specific requirements brought us to that level. So now you're coming in to our shop not only needing to ramp up on those 3rd party frameworks, but you gotta learn and understand how we changed them too for our purposes.