> I kinda suspect programmer pedagogy is fueled by clickbait pretenders who find it easier to teach frameworks than the tough stuff like how to make a complex s

> I kinda suspect programmer pedagogy is fueled by clickbait pretenders who find it easier to teach frameworks than the tough stuff like how to make a complex system easy & practical to build. There's a lot to balance making these decisions at a project's inception. NIH bias can cost you a lot for no benefit beyond self-satisfaction. There's a good chance making something with a current stable framework and migrating to a new one down the road will have taken far less time than making the initial RYO version. You'll also be able to hire people who already know how a big chunk of your codebase works, and lots of your underlying functionality is already documented. Additionally, pedagogy is very different from practice. Most of the time when young me decided to do something the hard— but "more elegant" and "simpler" "more correct"— way rather than using a library or something, it was because I didn't actually know how hard the hard way was. Those are mistakes you only make once. It's true that some people use frameworks because they don't understand how to do what frameworks do under the hood. A lot of other people use frameworks because they know exactly what it takes to recreate what that framework is doing under the hood. That obviously doesn't work if your code uses very little of what the framework offers— but they are generally designed to bring a lot to common use cases, and can save you vast amounts of time, energy, and money if judiciously applied. Just like any other tools, they've got their good use cases, bad use cases, and ways to outright abuse them. A good understanding of your requirements, the preferred methods to address them, and the current tooling available is the way to decide which of those scenarios a framework would fit into.