"You don't know what you don't know", so for me code-reviews were always extremely beneficial. Not only getting my code reviewed, but reviewing other's code. By getting my code reviewed, I'd be made aware of inefficiencies or improvements that I was not aware of, and by reviewing other's code, I became aware of techniques and strategies for writing better code. I think a social aspect to development is very important for improvement.
Another way I have improved my coding skills in the past is to take note of things I am unfamiliar with and look them up. A key to growth is learning new things, so it's important to not ignore things that you don't know, but to actually go look them up. I often go down a rabbit hole doing this, and it takes more time, but you will learn a lot. When researching a topic or how to do something that I don't know, if I encounter something else I am unfamiliar with, I either look it up immediately (if it blocks the current problem I'm on) or I make note of It and make sure to look it up afterwards. This way you are always improving and working to fill the weaknesses in your skills/knowledge as you come across them.
Similarly; learn new frameworks and languages. As you learn things that are unfamiliar to you, you will start to understand why they were designed (or evolved) that way. You can then decide whether you agree with the decisions or not from an informed perspective.
Try looking at Stack Overflow questions in a particular subject area. If you can answer 80% you're probably on top of it. If you can answer <20% you're probably a long way from mastering that subject and need to practice more.
Many of those questions probe really odd behaviours you'll rarely see, so they're great training. 95% of what you do as a developer uses maybe 1-2% of your actual knowledge. It's the remaining 5%, those ugly bugs, those quirky edge cases, that really test you.
The more you can expose yourself to those outliers, the more quickly you can gauge your knowledge. It helps assess if you're really good at just going through the motions, or if you actually have a deep understanding.
If you are looking to advance your career, you might want to consider focusing on understanding large scale distributed systems architecture rather than programming.
Programming skills, that's great. What about your non programming skills? Communicating, persuading, domain modelling, being able to explain your design decisions. They can be as important as programming itself, so don't neglect them.
I'd agree particularly with domain modelling and being able to explain your decisions. Working on those helps both technical and interpersonal aspects of your work.
I go about it in a bit of a round-about way. I'm a pretty introverted guy, so I make a point to work on soft skills like communication or public speaking to do demos. I've found that by getting out in front of others, they'll inevitably have questions for you, some of which you can't answer. If you let them know you'll get back to them with the answer, you become the "go to" person and you have someone else find an area you can improve on. The more you do this, the more you'll learn and eventually everything kind of falls into place.
One thing that is very valuable is human feedback from coworkers. However, like most communication, there is a skill to getting and receiving feedback. The book Thanks for the Feedback from the authors of Getting to Yes is a well-written and presents some solid implementable ways to improve how you handle soliciting, interpreting, and healthily responding to feedback.
Oddly enough, I benefitted from interviews early in my career - engineers probing for my knowledge boundaries would usually find some technical questions where my knowledge was weak, so I'd make a mental note to learn about that thing later.
Figuring out flaws in your development process can be harder, but it's worth asking for coworkers/manager for insight, they can often see what you don't even think about.
In terms of improving comfort and knowledge of new tech, I do personally projects and try to incorporate one new tool, language or framework every time.
Cooperative coworkers who still compete in the spirit if play (Lao Tzu). HR and the low trust/greed driven SV economy make it hard in the bay area, but other cities like Denver and Minneapolis are where I've met best friends who are also passionate programmers. Still looking for an answer myself locally as I've not found many growth minded programmers who also want to/are able to cooperate here.
For instance when I started doing stuff in mvvm in WPF it was a bit tiring. But then I also stumbled onto knockout.js and then I used mvvm in two different ways then common patterns clicked in. If you see some improvement area maybe try it from different angle, even better from multiple angles.
I define weak spots in terms of things I'm trying to accomplish. If I'm weak in areas I'll never need, then who cares? When trying to accomplish something you'll find out pretty quickly the things you need to improve and be dragged towards improving them fairly naturally.
Another way I have improved my coding skills in the past is to take note of things I am unfamiliar with and look them up. A key to growth is learning new things, so it's important to not ignore things that you don't know, but to actually go look them up. I often go down a rabbit hole doing this, and it takes more time, but you will learn a lot. When researching a topic or how to do something that I don't know, if I encounter something else I am unfamiliar with, I either look it up immediately (if it blocks the current problem I'm on) or I make note of It and make sure to look it up afterwards. This way you are always improving and working to fill the weaknesses in your skills/knowledge as you come across them.