There are plenty of sources to learn from aside more experienced colleagues: books, blogs of skillful developers, Stack Exchange, lectures/conferences, etc. Code reviews are also crucial, and CodeReview.SE is a precious resource.
Let's see how it could work on an example.
You're reading a blog post which mentions a term "ETL". You don't know the meaning of it, but from this article, you vaguely understand that it is a sort of process or workflow which moves data from some data support to another.
You go to Wikipedia and other resources and gain a more precise vision of the thing. It's still not very clear when would it be useful to use an ETL. After all, it seems much easier to write an SQL query which will do all the work, rather than spending too much time building a real ETL.
To answer those questions, you borrow a book about the ETLs from your local library. It explains that some extract-transform-load processes are not easily doable with a simple SQL query: not only the extract phase can deal with several, diverse data supports, not just a relational database, but also the transform step can be very complicated for both validating/normalizing the data and mapping it.
You now have a clear vision of what is an ETL, how to use it and especially when you need an ETL and when it is not an appropriate tool. Meanwhile, you've implemented a small ETL as a personal project. This project allows you to discover some points which are not clear enough for you and are not covered by a book. Those points being rather abstract and not related to the source code, you post a question on Programmers.SE.
When you have an opportunity to build one in your company, you start creating it. You have a few issues. Some are related to code; you post questions on Stack Overflow. Others are related to the database; you ask the questions on DBA.SE.
Finally, there is a conference done by a highly skillful developer about how to optimize ETLs. You attend this conference and it gives you precious hints about the enhancements you can do for your project.
You also start following a blog of a developer who was working on different ETLs for years. It's interesting to see the different approaches, and through this blog, you learn about ECCD; you're interested, so you borrow The Data Warehouse ETL Toolkit by Ralph Kimball, the book which talks in detail about the "extract, clean, conform and deliver" process. The same blog also mentions lots of applications intended to create ETLs without programming skills. This is particularly useful for the ETL you've done for your company, since your boss, non-techy person, constantly asks you to do some little changes to what you've done.
IMHO, the difficult part, when you don't have a mentor or a more experienced colleague, is to discover things, and by discover, I mean pass from the state "I've never heard about this thing" to "I've heard about it but don't know very well what it is".
If somebody reviews my code and says that I really should start using some style conventions, with a little curiosity I can find that in programming, there are different styles of writing code, that one should stick with a style for a given language and codebase, and that many languages have tools to enforce a style (like StyleCop for C#).
If nobody tells me about the style, how would I know that such a thing exist?
That's where resources such as blogs or Stack Exchange are handy. Wikipedia wouldn't help (unless you spend days hitting random pages about programming), and books rarely talk about those things.
The same applies as well to patterns and practices or things which are less related to code. For example, I hardly imagine some developer waking up in the morning telling himself that he must learn something about ITIL while he never heart about ITIL before.
Once you discovered a new term, it is pretty easy to learn about it. If you've given a new term "code contracts" and you're a C# developer, you can easily find enough information yourself on MSDN (or, better, in Jon Skeet's book).
When I work with interns, I always notice that the best ones are those who were curious outside their lectures. They may know that there is a thing called functional programming even if none of their teachers never mentioned it, and while they may not know any functional language, they are still able to explain in general terms what is FP and how is it different from other paradigms. They may know about Agile, or about Unicode, or about partial-trust/sandbox model, just because they were reading blogs and using Stack Exchange, rather then simply attending their lectures.
Even when they don't have a mentor, they still learn all those things which are not told in college.