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.

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.

Discovering things

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).

Curiosity helps

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.

I’m in a similar situation: we’re a small team and our core development product work is mostly incremental changes on a code base that’s a few years old.

A few techniques I’m using to stay up-to-date and improve my skills.

On the Job:

• Read: books, blogs, PR materials. I follow a number of RSS feeds. When the O’Reilly deal of the day is on a technology that I haven’t heard of, I read through the description of the book. If the technology has much relation to anything I’m working on, I spend five or ten minutes researching it in a little more depth, similar to MainMa’s answer. I repeat this with a few different RSS feeds.
• Build a training plan with your management that can be supported with company resources (time and/or money)
• Contrary to most programmer’s tendencies, try to embrace change and new design options. Change for change’s sake isn’t good, but I believe too often developers avoid using a new design or framework because of change. This is a fine line to walk, and don’t rush into binding decisions, but keep an eye out for new ways of doing things. Some changes can have unexpected benefits: moving to DVCS let me experiment on our code base more easily and try new technologies there.
• Some people like conferences; I’ve found that the payoff is small for the time invested.

Outside of work:

I’ve found that working on my skills outside of day-to-day work is critical. The freedom to experiment, make mistakes and pursue interests keeps me engaged in IT. If I only had my on-the-job projects and needed to limit my learning to what was immediately useful, I would quickly burn out.

• Get involved in a non-work project. For me, this is developing a functional website related to a personal interest. I refactor freely, and actively try to experiment with different technologies. Contributing to Open Source will get you exposure to other people’s code as well. This will also give you good material to share for interviews with the company that will have more experienced developers.
• Code Camp: If there is a code camp in your area attend. Because these aren’t during work hours and are free, you feel the freedom to attend any sessions for topics that interest you personally. Compared to typical conferences, these are usually local and cover wide swaths of technology, so I believe there is more concentrated value.

And don’t forget to visit SO or Programmers.SE frequently.

The answers here will likely be of great help, but I would like to stress something: nothing can replace working with someone better than you (for arbitrary, and personal, definitions of better) for 8 hours a day, 5 days a week. That much is certain.

If you’re the type of developer who always wants to get better, always wants to learn, then you will have to go to a different company eventually. That much is inevitable, and should be planned for.

When you find the company that’s right for you, you’ll find that you can continue to grow within it, than grow out of it.

Software development is a team sport. Like a sport, to play at a very high level, you need to be with and compete against others who do the same. Look for opportunities to move around.

Remember that practice makes permanent, so if you are not constantly working toward better technique and knowledge, if you work in isolation with no critic or role model, you may find that your skills don’t grow.

Worldwide, things are getting more competitive, so expect your niche to be temporary, and prepare for the kind of opportunity that meets your criteria for satisfying work, while at the same time, takes you outside your comfort zone to work with a superior team.

Before I get to any suggestions, I have to say that I was in a very similar position just over a year ago.

If you are getting the projects done, but you feel that there is a lot of space to improve, than that’s a good thing.

On one occasion I didn’t have a technical ability and confidence to complete the project. Often I would buy a book, I would read a fairly technical blog and would find myself “out of my depth”. I think the biggest problem for me was the fact that I didn’t have exposure to any large enterprise applications. Quite often I would do something well, but I wouldn’t have anybody by my side to validate what I’ve done.

This was demotivating and challenging, so I see where you are coming from. How did I address this issue? I left a company and joined a well established software development house, which has helped me to gain a lot of experience in the past year.

Unless you want to leave the company, I would suggest books that have been written by the pioneers of our industry. I would start with The Pragmatic Programmer by Andrew Hunt. The book contains tons of useful analogies that are very easy to remember. First few chapters of this book have encouraged me to pick up a very different programming language to the one we use at work. I’ve started to read non-technical literature – I now believe that reading novels and science fiction will make me a better programmer. Writing essays isn’t far away from writing clean code. Some writers are good and some are bad. This book made me care about what I write. One of the analogies is called “Broken Windows”. You leave a car abandoned on a street for days and nothing happens to it. Once you break a single window, the car will be probably destroyed on the next day. Code is no different. If you see broken or poorly written code, then fix it right away, don’t just leave it there because sooner or later it will come back to “haunt” you. Once you start working your way through this book you’ll pick up dozens of similar analogies that will make you think about code in a different way.

I would then suggest you move on to Clean Code by Robert C. Martin. This book is more practical as it forces you to read bad and good (clean) code. Author uses code samples from one of the open source projects. You say there is nobody to guide you. There is a perfect opportunity to look at somebody else’s code, compare it with your own, and see how you can improve it. To me reading this book was like shadowing somebody working on a project. The book also makes a strong emphasis on the easiest hardest thing – separation of concerns. The author has asked pioneers of our industry what they consider to be a “clean” code. Once you read their answers, you’ll be able to compare them to your own opinion on what clean code is all about.

Finally, have you considered working on open source projects? You will be collaborating with other, probably more experienced developers who will be able to review your code and point you in a right direction.

As I’ve said in my original answer, it won’t happen over the night. I’ve been doing this for few years now and almost every day I find out that I have been doing it wrong.

Good luck!

Practice solving problems. Read and work to understand others code (github is a great resource for this) and submit improvements to it. Doing consulting work can really help you broaden your skill set.