I had the pleasure of attending @media2006 and was lucky enough to meet the eloquent cheese lover and design extraordinaire Jon Hicks. He also presented "Being a Creative Sponge" a hands on look at collecting inspiration from places you may not necessarily look and using it to fuel your own creative process.
You can find a recently updated version of the presentation on Jon's journal, or if you are hoping to stage a factually accurate sitcom based around the popular 2006 conference grab the original one instead.
The main catalyst for this post is GitHub. Who'd of thought that a simple but powerful version control system could be so exciting, and build such a strong community. It goes to show what a good idea can become.
This isn't a post about Git or GitHub (maybe later) but if you haven't checked it out, go and signup, find some projects you dig, follow along with me and maybe get stuck in by pushing your own personal stuff online.
Right now though, we're not interested in what these things do, it's more how they do it, what code do they use? What structure and organisation do the employ? What common patterns can we find, and what are people saying about them? Leave that documentation behind kids, go straight for the source.
Learning a programming language is only the first step in mastering it's many quirks and benefits.
You'll need to know what it can and can't do, efficient ways to produce effective, beautiful and flexible code. The common patterns, idioms and conventions that exist within the language are what makes it special. Learning these is going to make you a better programmer.
What better way to learn than by looking at the experts, absorbing their code, and applying their knowledge to your own experiments.
You're not going to "get" everything straight away - it's going to push boundaries and do things you didn't even consider but that's fine because it's all here for you to learn from. Don't panic if you get lost on something, just follow it through, you'll be surprised how well things start to sink in.
Fluency takes time, lots of time. My personal focus is Ruby what a mystic, intricate and expressive language. But it'll be forever before I am really good, for now just pick little bits, flourishes here and there which you can mix with your own understanding to make something worthwhile.
Usually the code will speak for itself, but when it doesn't you can turn to the many commit messages and comments that go with every line.
What are people saying about this, what are they asking? This well help shed some light on bits that don't click and will help to explain the design which lies behind the implementation.
Don't be afraid to find things out for yourself - you're a sponge now, and sponges try to absorb as much information as possible.
A good example of this is when developing with a framework or on a platform - your gut reaction to find something out is to look at the documentation. But why not go deep into the library, find out exactly how a function or object is implemented. Work through the code and find out if it's going to do what you need. If not, you already have a foundation to build from because you have seen how something similar has been implemented.
Doing things this way also helps to remove some of the magic that you get from using a framework. All the more valuable if something goes wrong, you won't be afraid to dive in and get your hands dirty.
When you sit down tomorrow to build something new, don't just write but read as well - the more you understand the better you will be at creating.