Pitfall #1 - Not asking enough questions.
Every new employee wants to make a good impression and programmers are no exception. The question is what price is reasonable to pay to make that impression. It's all too common for a mentor to ask "Hey Charlie, what have you been up to for the past 3 hours?". To which Charlie answers "I've been stuck on this problem forever and no matter what I do, I can't figure it out!". Many times that "enormous" problem is really quite simple for a seasoned developer to solve.
Fortunately, the solution is quite simple. If after you've given it your best shot, you still can't figure it out, don't be shy, ask, ask, ask. You have a mentor for a reason. Your boss knows you're new in the field (so does your paycheck!), that's why you were given a mentor in the first place. There is absolutely no reason to pretend you're Mr. know-it-all. Aside for your honesty and integrity, asking questions is a critical part of the learning process. You will learn problem-solving skills by following their thought process and watching how they approach a problem.
If you don't have a mentor, you should seek help from your more experienced colleagues or online forums such as Experts Exchange. Even if you're afraid of becoming a nuisance, remember that every experienced developer went through the same stage in their professional development, so they should be understanding and accepting of it. Just beware that you're not asking others to do your work for you!
Pitfall #2 - Lack of knowledge
A programmers experience isn't measured only by the lines of code written or the number of years spent writing them, although some employers do seem to think so. One of the most important aspects of a programmer's experience is the number of code lines one has seen. By reading a lot of code one gets a feel for good programming practices, but even more important, are the frequent problems and techniques of solving them that you pick up along the way. While a new programmer may spend hours trying to overcome a hurdle, an experienced programmer may be able to solve it in a matter of seconds or minutes using these invaluable techniques (be they generic or specific to the particular language being used).
Becoming more knowledgeable is a slow and gradual process but luckily there are two things you can do to accelerate the process. 1) Make a point of reading (and understanding) as much code as possible. Preferably dedicating a given amount of time daily to this task. 2) Debugging applications that were written by other developers. One of the most powerful ways to learn is to figure out why what should have worked didn't.
Pitfall #3 - Reinventing the wheel
Part of the beauty of programming is the ability to take advantage of code written by other programmers as a starting point for the specific task at hand. Just as the physicist doesn't have to reinvent the Theory of Relativity to apply it to his work, a programmer does not have to rewrite existing code. Whether it is only several lines or even a whole library, one should most definitely use existing code. It will save much developing and debugging time, and so enabling you to concentrate your efforts on developing your own original code.
Many beginning developers, perhaps in effort to prove their abilities, tend to try and re-create good working code. As long as the code license permits using it in your specific situation, don't hesitate to do so.
However, when using code written by other people, you should make sure to give credit to the author/s in your projects comments or documentation. Not only out of courtesy (which is important too) but mainly so you will know where to turn if you need help. Another critical issue is understanding the code, which brings us to the next pitfall - using code you don't understand.
Pitfall #4 - Using code you don't understand
Contrary to those beginners who tend not to use code written by other programmers, there are those who will use other programmers code whenever they can without really understanding what it does or how it does it. Many times the copied code is not written well, may be buggy or worse yet, totally not what's required for the project.
Whithout understanding the code, you are bound to run into bugs at one point or another. Even if the code is good and your implementation is great, you still have to support it, a task that is impossible without an understanding of the code.
Pitfall #5 - Know when you're done
Much has been said about the definition of "done"
, or in other words when can we declare "Mission Accomplished". Most beginning developers belong to the school of thought that "The main thing is that it works". After spending so many hours developing and debugging, who can really blame them, the code swims before their eyes, and "as long as it works, who cares", Right? Wrong. Before declaring victory go through this checklist: