Rule #1: Never ever stop tinkering or hacking on your own interests.
Rule #2: The passion to code will come and go, but keep your mind and body razor sharp with quality food/exercise/sleep.
Don't try to reinvent the wheel. Every problem you're trying to solve has probably already been solved.
Verify all of your assumptions - ask questions, and realize the context the answer was given (i.e. the same answer may literally not apply to production vs development enviros or one language/API vs another).
Learn how to debug (this is an art), write tests, formal and informal QA procedures, write documentation, and how to get your code pushed upstream (the process) without breaking the system or anyone else's code.
Even if you've mastered the problem domain, most teams limit the ability to contribute too much the first couple of weeks because you need to earn the trust of your team (usually via a combo of defect-free code, humor, and general geek knowledge). Once trust/confidence in your ability is established, you will have plenty to do, and lots of guidance if necessary. But you may not be able to implement your idea for a new foo() in the product until you have reached that point. But watch out for NIH syndrome too.
Rely on more experienced members to help you organize your code files and assets to begin with - align with whatever the team expects. There are project standards, naming conventions, etc. and most of the time it's not written down. Or self-conflicting / clear as mud.
Don't be the dev that delivers sub-sub-standard code that's full of bugs. It's OK if it happens at first, but understand why it happened (root cause analysis?)
If you get stuck, please ask for help (or pseudo code) sooner rather than later. Like an hour or less. Some team members will be better teachers than others.
Good luck and happy coding.
 Consult experienced wheel builders first to make sure that it's your ONLY option.
I recommend this book: http://www.amazon.com/Debugging-Indispensable-Software-Hardw...