I can't think of any substitute for experience. You can read and study what you call concepts and patterns, just like you can read about baking a cake, but you can't get experience from study. You practice, make mistakes, stretch your abilities every day, and with luck you find good mentors.

Until you've seen most of what the software industry can throw at you, study isn't that useful. But after you've seen it all you'll be quick to glean the relevance and importance of new concepts when studying.

Your focus should also shift a little bit more towards helping others, thinking about where the whole team is going, etc.

But give it time. As long as you keep learning, you will get there. :)

Another book recommendation is Head First Design Patterns - the one I read used Java in the examples but I learned better with the style of that book than a textbook style. There are probably a lot of design patterns books out there including the original by the "Gang of Four".

The most important thing after reading about these patterns is learning when to use one and to do that you just need to go use them. Some caution though, I found myself putting patterns into use more frequently than was probably necessary simply because it was a new thing.

People like to debate this because they built an ego around working for a title at some megacorp by way of politics. These people are also completely oblivious to how the CTO also promoted their non-technical pal from high school to senior principle staff architect.

One is treating your team well and developing the juniors under you, including understanding that each individual may have different needs or require a different approach.

Two is that the best theoretical technical approach is not usually the best real life approach. The number of times I've seen technically elegant code fail because of human systems is quite high. A real example... Yes, I see you used maps and spread operators to concatenate shared vs core values in a CSP file that's shared between multiple sites in a monorepo. How do you think we can maintain that between multiple teams when we don't have clear delineation of ownership? The code works elegantly, but the human processes around ownership to maintain it are absolutely garbage. You should duplicate the shared CSP for each site and task them with stripping out any unnecessary entries for their own file/site. If not, then at least we can open vulnerabilities against individual sites. But hey, telling my TL that didn't work so now we're in a shitty position and I got a low rating for disagreeing.