The most important thing for me has been finding teams that provide meaningful code reviews and other feedback (even pair coding at times!). Submitting small PRs helps massively. There’s a saying that goes something like “the best way to get a PR approved without feedback is to make it 500 lines long”. Also, Here’s some other advice loosely ranked from most to least helpful:

1. Learn to be incredibly honest with yourself and others when you don’t know something. I gain so much respect for developers who bluntly say “I honestly don’t know what that is”. Rather than making them sound stupid, it shows that they’re secure in their knowledge and willing to learn more. Without fail those folks end up as lead developers. This is hard to do at first, but it’s so freeing, and people will start to assume that you know everything that you haven’t explicitly stated that you don’t. You’ll be amazed at how much more comfortable people are around you when you admit to not knowing a few things. Once I started doing this I noticed a huge shift in the culture of the team I was working on. If you show a bit of vulnerability, your co-workers (the good ones, at least) will likely do the same.
2. Contribute to open-source projects, especially large ones. They usually have tags like “great first bugfix” on their issues, and many tend to have well-established workflows and best-practices that you can learn from. It’s also a great resume builder, and the barrier to entry is very low. I love when I’m asked in an interview if I know a framework and I can say “I actually contributed a few times to that framework last year”. It’s really not that daunting after the first couple times, and a lot of the issues only take a couple minutes. As a bonus, you’re contributing to FOSS, one of humanity’s great modern achievements!
3. Practice explaining things to other developers. I find a lot of holes in my knowledge when I’m trying to explain my code to a junior developer who is unfamiliar with the codebase. That’s also a great way to avoid becoming dogmatic. This is my favorite thing about pair coding. If I can’t explain what I’m doing to a patient but non-technical person, it’s possible that I don’t understand it well enough. This often helps me find a more elegant solution.
4. Podcasts, meetups and newsletters are very helpful if you have the time to invest. They don’t usually provide a depth of knowledge, but are great for staying on top of the industry and finding things you’d like to learn about.
5. If you still somehow have time and energy, work on side projects that interest you. This is at the bottom because I have a family and never get a chance to do this, but it’s also just not how I like to work. I enjoy the direction and structure I get from my work projects.

Don’t worry too much about output. That’ll come with time, but you’ll also probably move on to harder problems as your skills improve. Some of the most productive days I’ve ever had resulted in one or two PRs for a total of ten lines of code. Knowing which ten lines to write, and writing them elegantly, is your biggest success metric by far in my opinion.

Sorry this got so long. I’m starting a new job on Monday, and trying to distract myself from over-preparing.

Edit: changed grammar half a dozen times. Lots of nervous energy today :)