Look into problems, you'll find solutions. Look into solutions, you'll find problems.
Pick any one stack, build some simple projects and then expand on it. You would also want to be able to read well written code from others on github and learn from those.
If something fashionable looks appealing, I would say, "drill down and understand the core of what pain point it's addressing". If you are convinced, check out "how you would have done it otherwise", and if you are happy with the fashionable thing, add it to your "fashionable thing" budget. Keep that budget tight. Be ready to revert at any time.
God, I love this line.
Our industry, especially these days, is flooded with "solutions" that promise much - and the best ones do deliver; but what's suitable in an enterprise environment can be a huge mismatch and complexity cost for smaller companies, individuals, or for research purposes.
I heartily agree with the grandparent post, to focus on what the problem domain requires, to use tools and dependencies that specifically support that goal.
Too often we see a framework, library, language or tool used for the sole reason that it's what the big players use - basically driven by popularity and inertia. There are advantages to buying into an ecosystem or particular scalable approaches, but only if it suits and serves your purpose.
As for writing better code - as many comments point out, the best way is to read and write lots of code, study books, follow the best works of people in the field.
It helps to start with the specifics, I think, by having (or creating) a problem to solve, or a project with clear goals. One can start with the simplest, "naive" approach, to solve the immediate needs - often that involves finding off-the-shelf libraries. Then, consider ways of improving the logic, refactoring, maybe dig deeper into the libraries to understand how it's organized.
There are some practices that make your app easier to manage, but you need to understand in which circumstances you need to use them.
A lot of the successful companies that are out there, got there from running a simple Django/RoR monolith until they were 60+ engineers.