User Interface best practice documents are a good start. However...
UI's are difficult for programmers to get right for one singular reason: programmers think differently than end users. Programmers have an entirely different mindset than the users of the software, and have a different perspective on what makes sense in a user interface. Until a programmer sits in on a focus group, and sees how easily users can get confused and distracted by what seems simple to a programmer, they will never understand that.
Consequently, there are tools that have evolved to help discern what needs to be in the user interface in order for your users to comprehend it and, more importantly, to be able to use it effectively. One of these tools is paper prototyping. Paper prototyping works because it focuses both the programmer and the user on program flow, rather than subjective incidentals like color and layout.
Being good at design doesn't necessarily mean you understand psychology. What it does mean is that you can open your mind to the end user's mindset, and have the skill (with a little practice) to coax out of them what they need from the interface via actual interaction. Your best science is letting the users tell you (by observing their interactions) what works and what doesn't.
Microsoft uses focus groups to test their interface designs, watching users from behind one-way glass. Once, when they were testing the new Office Ribbon, they came across a user who was a savant at using it. He worked faster than any of the other users. When the session was over, they interviewed this person and found out that he was using the mouse wheel to scroll through the tabs as a shortcut...a "feature" that was accidentally left in the prototype prior to the focus group. That feature is still in the ribbon today.
http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx