In this recent post to his blog Brian Smithwick talks about the "locked box" that developers can sometimes restrict themselves to - getting to comfortable in the tech they already know and not branching out.

Jason Austin gave a great presentation at CodeWorks Raleigh recently about cultivating one's passion for software development through side projects -- safe spaces where we can play with new technologies and techniques. The point's well taken: as developers, we're probably putting most of our energy towards the thing that must be solved, that keeps us employed, that pays our bills. [...] And so all of us, at one time or another, end up in a backwater of our own devising -- a locked box.

He also puts an emphasis on collaboration and community as it relates to becoming a better developer. By interacting with other code and other projects' developers, you learn not only more about other ways to develop but are exposed to ideas you may not have come across on your own.

I'd add that active participation in the local community is just as important though: the opportunities for exposure to new ideas outside your sphere are greater than your feed reader will probably provide, and the depth of information that you can get in a conversation may be better than any blog post or man page.

Kevin Schroeder has posted about an idea he recently came across (in this article) called the "Curve of Talent". Kevin's post expands on the idea and makes it a bit more relevant to the "how can I be a better developer" question asked quite often.

I get asked, quite frequently, about how people can be better programmers. Why they're asking me, I have no idea. But what I usually tell them is to be curious and be creative. Waste time. Now, I don't mean "wasting time" by playing Quake (one of the best adrenaline-based games of all time), I mean taking time to learn new things and try new things... sometimes without permission and sometimes before or after normal work hours. (Though not ALL the time. If you always are working you have priority issues).

He recommends working on side projects - ones where you can be free to explore new technologies and ideas that might not fit in the confines of your day to day work. The article from Eric Paley talks about "C level performers", people who may or may not have the experience, but just can't seem to make things happen. Kevin's recommendations can help you break out of this "C" mold and get on the path to not only better yourself as a developer but also make you more equipped for future projects.