Just for another data point, I'm a "senior" developer (been programming for 30 years) and I tend to look more at frameworks than languages. I really think that

Just for another data point, I'm a "senior" developer (been programming for 30 years) and I tend to look more at frameworks than languages. I really think that starting from first principles allows one to end up with an elegant solution, regardless of whatever errata is present in a language. A good framework is the elucidation of an idea with the edge cases covered so that you don't have to reinvent the wheel. It should give you the tools you need to integrate with your code and then get out of the way. Specifically, take something like Laravel. It's based on Ruby on Rails, which borrows heavily from .NET. Personally I think that Ruby is a decent language that gets a few things right, despite some early compromises to get closer to the metal which caused some unwieldiness down the road. However, Ruby on Rails has a brutal learning curve unmatched by just about any other framework that I've learned. And the end result unfortunately succumbs to being too opinionated due to emphasizing convention over configuration too much IMHO. I think that's why it fell from favor, and personally I wouldn't recommend it for new development. Whereas Laravel does a lot of what Rails does, despite using the "hackier" PHP language and less syntactic sugar or magic under the hood. The companion Laracasts are mostly exceptional. I would even go so far as to say that if you want to learn Ruby on Rails, learn Laravel first. That way you can build on context and be comfortable with Rails in a few weeks rather than the months it would take to learn it from scratch. You'll also notice the inconsistencies in Rails more and be able to work around them so your code is conceptually correct, rather than evangelize why their existence is needed or that they're the "one true way" to do something. What I'm trying to say is that after using Ruby on Rails, I'm still not sure what problem it's trying to solve half the time. It seems to be structured in a way that solves issues encountered late in a project, but it's never really clear why one path was chosen over another. Like I solve a problem in my head, then have to translate it to the Ruby on Rails way. I don't get that as much with less-opinionated frameworks like Laravel. I think the best approach is to provide as much functionality as possible with sane defaults but not force the user into a paradigm. Simplifying from Angular to Vue is another example of this. There are many others, but to play on this, it's one of the reasons why I'm uncomfortable with stuff like Kubernetes. Or even Unity for that matter. The more monolithic/enterprisy/opinionated something is, the more I'm skeptical of it. This idea of working from first principles (the way a new user might) is a way to think about how to go about writing code that junior developers can use, even if the concepts involved are senior-level. I practice this technique but it easily gets lost in translation and I find myself explaining the easy vs simple dichotomy a lot. It's probably even cost me jobs to be honest. But that doesn't mean it's wrong.