Changing code in one place all too often breaks code in a (seemingly) unrelated place. No matter how experienced you might be: you won't be able to predict the possible side effects that code changes can have. That's what gives our jobs that "thrilling touch"...
Back your code with automated tests!
You won't easily become aware of all your application's problems: some will only surface in very rare circumstances or with seldom used features. Although you cannot prevent or foresee all problems, you should at least make sure you're made aware as they happen.
Developing and keeping unfinished code separate from your production code is a sign of good breeding. However, not keeping your feature code up-to-date with other important development in your project will cause problems. Because the later and less often you integrate your new code with the rest of your project, the higher the risk of things not being compatible.
Integrate often! Make continuous integration part of your development workflow.
"Mike is the only one who knows this part of the code." And as it stands, Mike just started his 6-week vacation in the Himalaya... When code is developed by a single person in isolation, that code is fully dependent on that person. Whenever the developer is on vacation, sick, or busy with other stuff, that critical bug can't be fixed or that feature can't be added.
Consider pair programming and/or regular code reviews to share "code ownership".
Every piece of code solves a problem. And ideally, it should only solve a problem you have (or are very likely to have). Of course, an endless number of other problems can be imagined... but trying to solve them when you're not likely to actually have them will make your code more complex than necessary.
Make sure you don't overengineer. Keep things as simple as possible.
Any time you're looking at a programming problem, chances are that someone else has had the same problem before. And if you're lucky, the problem has not only been solved in a good enough way - but the solution has also been published. In that case, trying to write this code yourself would be the classic reinvention of the wheel - and a waste of your precious time.
Keep your eyes open for good third-party libraries that have stood the test in other projects already.
While external libraries can lighten your workload, they can (unfortunately) also bite you: when they introduce bugs, when they increase loading time, when their development is discontinued, when you simply have too many of them in your project to keep an overview...
Use third-party libraries only when you're convinced that they are of high quality - and you really need them.
Code rots. It's a sad but true fact. While some parts in a project change and evolve, others are left behind. These parts become liabilities over time. For example, because framework features became obsolete; or because the new code's demands aren't satisfied anymore.
Schedule time for regular refactorings.
Although most teams nowadays use a version control system like Git, they often don't use its full potential! Git has much more to offer than just "commit, pull, and push". Learning the more advanced stuff (from Interactive Rebase to Git's many "undo" features) can improve the quality of a code base tremendously!
Go beyond the basics and learn to use the more advanced features of Git!
If you want to take No. 9 - your Git knowledge - to the next level, I have a couple of tips for you: