When you first become a developer its much easier to learn new things with just a little bit of direction. You may not always learn the best way to do things, but you're learning. Eventually I found that I hit a plateau. I was technically knowledgable and could learn new technologies fast, but the quality of my code wasn't changing significantly. I've found that this happened because the feedback loops for this type of work is much larger. It can take you years to see why your architecture is unmaintainable, because it technically works and is much more subtle.
The new company has hundreds of developers, all really smart. We do peer reviews for all new work, which helps you learn from the experience of others. We tend to work in pairs, some people do actual pair programming, some people just bounce ideas and questions off of their pair, and all code is peer reviewed. It's very informal and isn't really written down anywhere, more a part of the company culture. My pair works on other projects than myself, we each have a number of projects we lead, but we're both very familiar with each others projects and could take over in their absence. Helps us learn from the experience of each other.
The other big thing that changed with the new company is the writing of tests. Prior to this, I hardly ever wrote tests. Now, I write tests for any new code. Sometimes this involves TDD, and sometimes it's just test-heavy development. Again, we aren't dogmatic about this, and there's often code that is untested. This is usually parts that are unreasonable to test, or wouldn't benefit much from tests.