I've been doing some work on my resume and my summary kept starting to sound like a manifesto. I decided it was better to just simplify the resume and turn this into a blog post.
Technology doesn't exist exist in a vacuum
People create it and use it. Taking time to understand the motivations and needs of clients and users lead to more informed decisions and ultimately make a project more successful.
The team owns the code
It should all follow a common coding standard. You shouldn't be able to tell Eric was editing this section because he left it littered with tabs, while everyone else uses spaces. It also means it's important for members of the team to review each other's code and give feedback. It's also important for people to listen to that feedback. Code review provides a good way to share knowledge: "oh, that trailing comma in your array will cause IE to blow up." Even if the review just points out a typo in a comment, it sets the expectation that other people will be reading and trying to understand your code.
Code needs to explain itself
If you're doing something that looks squirrely you need to say why so the next developer doesn't come along and "fix" your code. If you're putting in a quick hack to close a ticket, say so! Spend a few minutes to list the pros and cons that lead you to this solution so that when you're staring at the code a year from now you don't have to rediscover them.
Documentation is important
If people can't figure out how to use or maintain your product then it's not finished. The documentation also needs to be close at hand. This ties back to code needing to explain itself but also extends to UI, make the ramifications of a choice apparent.
It's worth spending the time to do something right the first time
Of course there are times when you need to just get it done and launch, but as layers of code accrete on top of it, you'll only find it harder to come back fix something.
You should play devil's advocate
I'm happy to take the other side and argue against each of these points.