Always code as...

In programming there's an old saying that goes like this:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- attributed to John Woods

I must say he's right. Fortunately there are usually no psychopaths hanging around on your legacy applications, but it's a good karma rule to adhere to. And you may end up maintaining your own code, which is an outcome I hope you had considered. :)
I'd like to extend this maxim with some other suggestions similar in form.

Always code as if you were pair programming (mental/social metaphor)
When we are pair programming, we have to explain what we are doing. We get a mindset that challenge our code to make it better. We never get angry at the machine or at a library's developers.
A benefit of pair programming is having a different mind that works over the same problem, so that there is a failsafe in place to stop bugs or technical debt from being introduced. But the habit of trying to explain, or at least state, a problem before solving it is a productivity booster, even if you only talk to a rubber duck. This habit is enforced by TDD too.

Always code as if you were paying your lines' weight in gold (financial metaphor)
The less code you write to solve a problem, the less code you'll have to maintain: code is widely considered a liability more than an asset (an high-level programming language is crucial here.) Moreover, there is a limit to the lines of code you can write every day while maintaining an acceptable level of quality.
You should favor verbosity only to improve readability and encapsulation: the trade-off is difficult to find here, but introducing new domain concepts as classes or methods is often a valuable asset that balances the code's hindrance, as long as they are significative for the application (e.g. customer's credit card number vs. customer's eye color.)

Always code as if you had to deploy and use your application at the end of the day
Which may be the case if it's a web application.
Portability is not a feature you can add as single user story: the best way to make an application portable, configurable, deployable and most of all working is to build it as simple as possible with these characteristics (a walking skeleton), and keep them while you expand the codebase with new features.
This practice reduces risk (chances that you may find your ideal deployment requirements cannot be met) and helps early automation of the most boring tasks, defining them clearly as soon as possible. Once the technicalities have been removed and a clean environment is ready, you will be free to work on the pure domain model.