I am compiling a rules of programming mindset for my team: What are yours?

Follow the SOLID principles:

Single Responsibility Principle (SRP)

There should never be more than one reason for a class to change.

Open-Closed Principle (OCP)

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Liskov Substitution Principle (LSP)

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Interface Segregation Principle (ISP)

Clients should not be forced to depend upon interfaces that they do not use.

Dependency Inversion Principle (DIP)

A. High level modules should not depend upon low level modules. Both should depend upon abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

Best Practice: Use your brain
Don't follow any trend/principle/pattern without thinking about it

Less code is better than more, as long as it makes more sense than lots of code.

Build Breaker Buys Lunch

Take part in open source development

If you are using open source code in your projects, remember to post your bugfixes and improvements back to the community. It's not a development best practice per se, but it's definitely a programmer mindset to strive for.

Never tell business everything!

Refactoring is part of your job and not something that is up for discussion. If you always add a little "estimated" time to be able to do necessary refactoring there won't be any complaints about it!

Declare everything. Never nest 15 functions into 1 variable.

It is never as easy as you think

This is in response to another answer, but does not contradict it! Both are valuable principles that should be followed.

Your code should be so simple that anyone who looks at it can understand what it does without reading any documentation.

But don't forget to document everything anyway.

If your API is not braindead-simple to use, there is something wrong with the API. Refactor it until it takes no effort to use correctly.

Before you write any code, research first to find out if the framework already has built-in support or extensible interfaces for what you're trying to do.

Some Things Are Better Done than Described

Don't fall into the specification spiral---at some point you need to start coding.

via The Pragmatic Programmer

Creating software is like.. building a house.

You can try building it without a blueprint, a plan, experience, an architect or qualified tradespeople.

As a result it will almost always cost more, take longer, and be full of future, ongoing surprises that need your time and money.

Just because someone can build a shed without a blueprint doesn't mean they should.