Two harmful mistakes every developer should avoid

There are several traits of a successful employee every hiring manager seeks for. There are as well several mistakes a developer should really avoid. Those mistakes usually cause much trouble!
When I set to hire someone, I tell him explicitly that I can't tolerate 2 of those unless agreed upon during the sprint/iteration life cycle.

Deadlines

A Deadline is a major thing, I like to call it a : holy date. Many developers don't get the importance of deadlines unfortunately. However it's simple: all teams depend on this date, business, marketing, pm and finance teams. When you have a problem setting this date, you simply screw everyone's life, starting by shifting business plans and then adjusting other plans accordingly.

That's why I ask new employees to take their time in giving estimations. If you need time to research something, then fine: ask for it and take it.

Use Gantt charts to do estimations. A task time shouldn't exceed 4 hours, otherwise you have to split the task to minor ones.

Add time margin to your estimation. Some developers tend to be optimistic. Certain problems might arise. That's why I ask all developers to add a margin of 2-3 days depending on the sprint/iteration length.

If something is blocking you then you need to raise it ASAP. If for some reason you can't meet a deadline, then raise it ahead of time.

Quality

Code quality is the most important factor in evaluating someone's work. However, that's not the reason of its importance. The importance of code quality comes from the old known fact; your code will be maintained by you or others in next iterations of the project.

If you deliver low quality code then, most probably the code will have to be rewritten after few iterations. Simply, you'll waste months of planning and work.

However, code quality has no clear standards in terms of expectations. This is something that you need to consider and revisit every while and then. I ask team leads to set those standards in both design and implementation. Personally, I like both the SFEMS and the SOLID principles.

Pair programming is by far, the most reliable option for code quality. Testing is another one with a little cost of time at the beginning of practicing.

Both deadlines and code quality are so much important factors that help shapes the ninga of you. Please work on optimizing those skills. Stick to your team lead and take his advice when needed. It's all about experience after all!