So what are you doing it for then?
To satisfy a political agenda?
Because you're a child looking for fun? (And will create yet another cookie-cutter framework named something childish.)
To satisfy a need for validation because you aren't an adult?
To make great products? (so someone else can make money.)
Because it's new and shiny and trendy and you need to keep up with the Jones's?
Why is an experienced coder so much more efficient than an inexperienced coder? Because they have learned many infrastructures, frameworks, and algorithms, have learned through experience not to make certain mistakes like over-complicating a problem or seeking clarity to a problem prior to coding it and thus understand the cost of requirements, and have picked up good design habitations like divide and conquer, coding without making assumptions, or multi-tiered architectures.
Most Managers don't understand the foundation of good software and great IT infrastructure are solid requirements. That requires a solid investment, like a building foundation, in analyzing the business; great managers know enough about a particular business that they can spot the mistakes analysts make in building requirements and vet them so they don't change in major ways. Do colleges teach any of this? No.
When Changing requirements meets improper planning and tight project budgets (which may be tight because the company is in trouble, or may be tight because the Project Manager is incompetent), it means over-working staff to hit those changes which produces cognitive pollution. That pollutes the code base with too many assumptions, and pollutes the staff's minds with bad habitations and expectations. Eventually like any pollution, it builds up until it becomes terminal; developers quit, the cost of making any change becomes terminal for the code base, and so forth. We've all seen it. More importantly you take a developer who's worked a 9-5, then spend 2 hours a night for the last 10 years learning advanced mathematics, or low-level compiler design, or other things that really create good habits and techniques, and you literally cannot introduce them to that environment because the environment won't be able to value them; it can't see through the pollution.
The tautology simply is the overtime exemption. If you don't have staff clocking in and out, there's not a chance in hell of you ever figuring out how much time it takes to do any project, which in turn, feeds the tautology. Very simple question to ask at an interview "Do you track the hours of your software developers?" "Well no." "Why would I want to work at a company, overtime-exempt no less, when the management has no idea how to estimate the hours consumed for a project?". We get into concepts like "We practice scrum and estimate the story points based upon"; you sound like a 5-year old when you start talking that kind of jargon.
The pollution sloshes around in the talent pool, and companies end up with poisoned projects because of it.