Because it's been established that Dr. House can only work if he has someone to bounce ideas off of, even if that person is the janitor.
One I would add is to not throw a fellow dev under the bus when talking with a user. Give praise to specific team members but take the hits as a team. It helps build comradery when you see a colleague take the hit for you and builds a certain trust amongst the team knowing that others have your back.
Yep. That goes beyond just development -- that's a huge management/leadership technique and is very important for any team, regardless of what they're trying to accomplish.
I think it is a chronic weakness of even good developers to write too early. First read!
My first year programming a project manager remarked, "I've never heard a programmer praise another's code. It's always, 'This is crap!'". That really stuck with me, and I've tried hard to be charitable and to really understand things before making changes. It's served me well now that I consult and freelance, but it also makes me less patient with programmers who dive in to existing codebases and immediately start making changes. In marriages they say "Seek more to understand than to be understood." There is something like that in software too.
I would also add working out your security model early (e.g., Which users have access to what functions in your application.)
6, 9, 18-22